Systems and methods for monitoring subjects in a physical space

Abstract

A system for monitoring a subject in a physical space, the system including: a plurality of sensors for detecting movements of the subject in the physical space; a data processing system configured to: receive from the sensors signals representing detected movements of the subject in the physical space, process the received signals to determine corresponding movements of the subject in the physical space, and select an action from a plurality of predefined actions, based on the detected movement; and one or more output devices for outputting a prompt based on the selected predefined action for the subject.

Description

[0001]SYSTEMS AND METHODS FOR MONITORING SUBJECTS IN A PHYSICAL SPACE Technical field The present disclosure is directed to systems and methods for monitoring a subject in a physical space. Some embodiments of the present disclosure are directed to tracking a patient's health status, including for in-home care applications. Background Due to ageing populations, many more elderly and / or chronically ill patients are living in their own homes rather than in dedicated aged care centres, hospitals or other types of care facilities. To facilitate safe and effective healthcare, patients' health metrics must be regularly collected and tracked; however, routine collection of these health metrics can be difficult, time intensive and insufficiently accurate or timely enough for in-home patients. For example, the patients' homes are typically remote from a medical care facility where the health metrics are more easily tracked, e.g., a hospital where nurses work. Further, for patients with physical, mobility and / or cognitive impairments, adherence to prescribed health routines, e.g., taking defined medications in a timely manner, is usually poor—and poor adherence can be a key driver of higher rates of morbidity and mortality amongst patients. Consequently, there is a general need for improved systems for monitoring and treating patients in non-medical settings. According to existing systems for monitoring patients that do not reside in dedicated medical care centres, medical professionals make scheduled visits to the home or dwelling of a patient to perform tests and record health metrics. Although the health metrics may be gathered accurately by the medical professional, there can be significant time intervals between each measurement, and significant time between measurement and assessment by a clinician, preventing updated data from being available to health care professionals for tracking the health status of the patient, resulting in a reduction of care quality. Further, if a patient were to have an adverse health event, such as a stroke, a cardiac arrest, or an injuring fall for example, and become unable to request or call for help, they would only be discovered when a visitor, such as a family member or medical professional, visits the dwelling to check on them. To address this problem, wearable wireless alert devices have been developed to allow a patient experiencing an adverse health event to activate the device to raise an alert; however, these devices require the patient to be conscious or physically able to activate or reach the alert device, which sadly is often not the case. Additionally, to collect some types of health data that enable a medical professional to accurately track the health status of a patient, a medical professional must visit the patient at regular intervals to perform the relevant procedures to collect the data. This is an onerous task and may be made more difficult due to an unavailability of medical professionals, remote location of the patient or any other such limiting factors. According to known processes of tracking a patient's health metrics, a remote health professional may have a check-in scheduled with the patient, wherein they have a predetermined time window within which to call the patient and record data about the patient. This data is usually self-reported after the fact. This requires a dedicated work force tasked to call the patient, and also results in low accuracy data due to a duration of time between the event occurring and the data being obtained / recorded. This is also restricting on the life of the patient, as they are required to be home at a certain time to receive the call. This results in inconsistently recorded low quality data, logged over long intervals, which is not optimal for patient health determinations. For example, self- assessments from patients can be an important health metric, especially to mitigate re- admission to hospital, but these generally require an in-person interview to obtain accurate results when patients have limited capacities (e.g., based on age or illness) (not just heart rate etc.), or at least a telephone conversation, and many patients do not use mobile / cell phones (up to 20%) or phone calls can go unanswered (e.g., it may take 5 calls to answer 8 questions). It is desired to address or ameliorate some of the disadvantages associated with such prior methods and systems, or at least to provide a useful alternative thereto. Summary One or more embodiments of the present invention include a system for monitoring a subject in a physical space, the system including: a plurality of sensors for detecting movements of the subject in the physical space; a data processing system configured to: receive from the sensors signals representing detected movements of the subject in the physical space, process the received signals to determine corresponding movements of the subject in the physical space, and select an action from a plurality of predefined actions, based on the detected movement; and one or more output devices for outputting a prompt based on the selected predefined action for the subject. In some embodiments, selecting the predefined action includes determining, based on the received signals, one or more events that have occurred, and selecting, based on the one or more events the predefined action. In some embodiments, the data processing system is situated in the physical space and is configured to receive signals representing the detected movements, determine a movement of the subject, select the predefined action, determine one or more events and output the prompt independent of an external data connection. In some embodiments, the data processing system uses one or more finite state machines to determine or select the predefined action and / or the one or more events. In some embodiments, the data processing system includes a rules engine. In some embodiments, the sensors are not configured to capture images. In some embodiments, the system further includes one or more input devices configured to receive a subject response to the outputted prompt, and to send the received subject response to the processing system. In some embodiments the processing system is configured to determine a further action and a further prompt based on the received subject response, for output by the output devices, thus providing two or more questions in the respective prompts for the subject. In some embodiments the subject response is recorded and stored in an internal data store of the system. In some embodiments subsequent to the subject response being recorded and stored, the subject response is communicated to a third party device. In some embodiments the one or more input devices include any one or more of: a sound sensor; a smart watch; a keypad; a touch enabled display monitor; a smart television; and mobile computing device. In some embodiments the processing system is further configured to select one from one or more predefined alert messages, based on: the one or more determined events; the selected predefined action; and / or the subject response. In some embodiments, the processing system is configured to select one from one or more alert prompts, subsequent to selecting the alert message, and output the selected alert prompt via the one or more output devices. In some embodiments, processing system is configured to communicate the selected alert message to one or more emergency contacts that are remote from the physical space. In some embodiments determining of the movement of the subject in the physical space includes: determining, based on one or more entry / exit sensors, that the subject is currently inside the physical space. In some embodiments, the sensors include two or more of the following types of sensors: bed sensors; seat sensors; latch sensors; door sensors; motion sensors; presence sensors; temperature sensors; step trackers; humidity sensors; noise sensors; fall sensors; light sensors; air quality sensors; fire sensors; smoke sensors; glucometer; panic button; blood pressure sensors; pulse oximeter sensors; heart rate sensors; weight sensors; impact sensors; and GPS trackers. According to some embodiments, present invention includes a method of installing a system for monitoring a subject in a physical space, the method including: installing in the physical space, two or more sensors for detecting movement of the subject in the physical space; installing in the physical space a data processing system configured to: determine a movement of the subject in the physical space; and select one from two or more predefined actions, based on analysis of the detected movement; configuring one or more output devices for outputting a prompt based on the selected predefined action for the subject. According to some embodiments the present invention includes a kit that when assembled provides a system for monitoring a subject in a physical space, the kit including: two or more sensors for detecting movement of the subject in the physical space; a data processing system configured to: receive signals representing the detected movement from the sensors; determine a location of the subject in the physical space, and select one from two or more predefined actions, based on analysis of the detected movement; one or more output devices for outputting a prompt based on the selected predefined action for the subject; and instructions that comprise the method according to the previous disclosures. According to some embodiments the present invention includes a system for identifying whether a change in a condition of a person has occurred: two or more sensors for detecting a presence of the person, wherein at least two of the two or more sensors are in mutually different rooms of a building; a data processing system configured to: determine, using a first sensor, a presence of the person in a first room; determine, using the first sensor and a second sensor, that the person is no longer present in the first room and a presence of the person in the second room; trigger, based on the presence of the person in the second room, an event; responsive to the event being triggered, perform an automated conversation with the person to determine whether a change in a condition of the person has occurred, wherein performing the automated conversation includes: (a) generating a text string, based on the triggered event or a response from the person, wherein the text string is representative of at least a portion of a spoken conversation with the person; (b) generating an audio representation of the candidate text string; (c) outputting the audio representation so as to be heard by the person; (d) determining the response from the person wherein the response is indicative of a current condition of the person; (e) based on the response from the person, performing steps (a) through (d) again, or determining that a conversation termination point has been reached; and responsive to determining that a conversation termination point has been reached, determining based on one or more of the generated text strings, and one or more determined responses, whether the condition of the person has changed. In some embodiments, the presence of the person in the first or second room is determined without performing optical based image analysis. In some embodiments, triggering the event further includes: determining, by the processing device, one or attributes of the first and / or second room; and wherein triggering the alert is further based on the one or attributes of the first and / or second room. In some embodiments, triggering the event further includes determining one or more of: a time of day; a day of the week; one or more medication schedules of the person; and one or more medical conditions of the person. In some embodiments, generating the text string is further based on one or more of: a time of day; a day of the week; one or more medication schedules of the person; and one or more medical conditions of the person. In some embodiments, the data processing system, responsive to the event being triggered, is further configured to determine one or more behavioural aspects of the person; and wherein determining whether the condition of the person has changed or not is further based on the behavioural aspects. In some embodiments, the data processing system is further configured to generate and output one or more reports indicative of the automated conversation and / or the behavioural aspects of the person. In some embodiments, detecting the presence of the person in a room includes, determining a period wherein the person is not in a room, detecting when the person enters the room, and continuously detecting the presence of the person while they remain in the room. According to some embodiments the present invention includes a computer- implemented process for monitoring a subject, the process including the steps of: receiving, from one or more of a plurality of sensors configured to sense the subject, signals representing physical properties of the subject; processing at least some of the received signals to infer one or more corresponding events of the subject selected from a plurality of predefined events; and in dependence on the one or more inferred events, generating corresponding prompt data to prompt the subject to provide information related to the one or more inferred events; causing the prompt data to be communicated to the subject; and receiving response data representing a response of the subject to the communicated prompt; and processing the response data to determine a health or medical status of the subject. According to some embodiments the present invention includes a computer- implemented process for identifying whether a change in a condition of a person has occurred, the process including the steps of: determining, using a first sensor of two or more sensors, a presence of the person in a first room, wherein at least two of the two or more sensors are in mutually different rooms of a building; determining, using the first sensor and a second sensor of the two or more sensors, that the person is no longer present in the first room and a presence of the person in the second room; triggering, based on the presence of the person in the second room, an event; responsive to the event being triggered, perform an automated conversation with the person to determine whether a change in a condition of the person has occurred, wherein performing the automated conversation includes: (a) generating a text string, based on the triggered event or a response from the person, wherein the text string is representative of at least a portion of a spoken conversation with the person; (b) generating an audio representation of the candidate text string; (c) outputting the audio representation so as to be heard by the person; (d) determining the response from the person wherein the response is indicative of a current condition of the person; (e) based on the response from the person, performing steps (a) through (d) again, or determining that a conversation termination point has been reached; and responsive to determining that a conversation termination point has been reached, determining based on one or more of the generated text strings, and one or more determined responses, whether the condition of the person has changed. Brief Description of the Drawings Preferred embodiments of the present invention are hereafter described, by way of non- limiting example only, with reference to the accompanying drawing in which: Figure 1 is a schematic diagram of a dwelling configured to monitor a subject in a physical space; Figure 2A is a block diagram of a system for monitoring a subject in a physical space; Figure 2B is block diagram of a different embodiment of the system of Figure 2A for monitoring a subject in a physical space; Figure 3A is a schematic of a system architecture of a hub and sensor arrangement for monitoring a subject in a physical space; Figure 3B is a schematic of a different embodiment of the system architecture of Figure 3A for monitoring a subject in a physical space; Figure 4 is an image of the hub device of Figure 1; Figure 5 is an image of the presence sensor of Figure 1; Figure 6 is an image of the bed sensor of Figure 1; Figure 7 is an image of the door sensor of Figure 1; Figure 8 is an image of the dynamic light of Figure 1; Figure 9 is an image of the output device of Figure 1; Figure 10 is a process flow diagram of a method for monitoring a subject in a physical space; Figure 11 is a process flow diagram for detecting a fall event of an inhabitant; Figure 12 is a process flow diagram for detecting showering of an inhabitant; Figure 13 is a process flow diagram for a method of playing a message via the output device of Figure 1; and Figure 14 is a process flow diagram for interacting with an inhabitant to determine a health status of the inhabitant; Figure 15 is a process flow diagram for identifying whether a change in a condition of a person has occurred; and Figure 16 is a screenshot of a check-in graphical user interface. Detailed Description The present disclosure is directed to systems and methods for monitoring a subject in a physical space. In some embodiments the subject includes a patient or an inhabitant. In some embodiments, the physical space includes a dwelling 100, such as a house or apartment. According to some embodiments, the present disclosure comprises two or more sensors, disposed within a physical space, the sensors configured to track movement and / or activities of the subject within the physical space. The systems further include a data processing system. The data processing system may be a computing device disposed in the physical space and in communication with the two or more sensors. In some embodiments the data processing system may include a hub computing device. The present disclosure is also directed to a method of installing a system 200 for monitoring a subject in a physical space. The present disclosure is further directed to a kit, comprising components and instructions, that when appropriately assembled provides the system 200 for monitoring a subject in a physical space. The system 200 provides for real-time autonomous monitoring of an inhabitant 145 and their behaviours within a dwelling 100. The behaviours of the inhabitant 145 may include entering or leaving bed, moving within a room, moving between rooms, taking medication, measuring various health metrics, such as blood pressure or weight, or any other type of behaviour that may be indicative of the health status of the inhabitant 145. The system 200 may achieve real-time autonomous monitoring using two or more of the same or mutually different types of sensors 210 to sense physical properties of the inhabitant. Physical properties of the inhabitant may include the movements of the inhabitant 145 within the dwelling 100. Physical properties of the inhabitant may additionally or alternatively include presence, temperature, weight, heart rate, sitting / standing / lying / prone position, blood glucose, blood pressure, blood oxygen, and / or any other relevant information about the inhabitant. The types of sensors 210 may include bed sensors 115, seat sensors, latch sensors / door sensors 120, presence sensors 105 (e.g., on ceiling / wall), motion sensors (not shown), temperature sensors (not shown), humidity sensors (not shown), noise sensors (not shown), fall sensors (not shown), light sensors (not shown), air quality sensors (not shown), fire sensors (not shown), step trackers (not shown) smoke sensors (not shown), impact sensors (not shown), glucometer (not shown); panic button (not shown); blood pressure sensors (not shown); pulse oximeter sensors (not shown), heart rate sensors (not shown), weight sensors 110 and / or GPS trackers (not shown). The present system 200 may determine, based on sensor data collected from the sensors 210, one or more inhabitant 145 care steps or actions to perform. According to some embodiments, the actions may be predefined actions, and the system 200 is configured to select one from the one or more predefined actions based on sensor data. The system 200 may, subsequent to determining one or more care steps or actions to perform, prompt the inhabitant 145 to perform one or more actions – to prompt the inhabitant 145, the system 200 includes at least one output device 250 (i.e., with a human-machine interface), including a speaker device, and / or a display screen. For example, the system 200 may determine that the inhabitant 145 has entered a particular room wherein the inhabitant 145 may be required to perform a self-care action, such as taking medication, and responsively cause an audio prompt to be played encouraging the inhabitant 145 to take their medication. In some embodiments the output device 250 may include a laptop computing device, desktop computing device, smart phone, tablet, bespoke computing device, or any other suitable computing device, for example. According to some embodiments, the system 200 may, after waiting a predetermined amount of time, prompt the inhabitant 145 to confirm that the requested action has been completed. The system 200 includes at least one input device 255 (i.e., with a human-machine interface) to receive input from the inhabitant 145. The inhabitant 145 may respond verbally, or via an electronic device (e.g. a phone or display panel in the dwelling). In some embodiments the input device 255 may include a laptop computing device, desktop computing device, smart phone, tablet, bespoke computing device, or any other suitable computing device, for example. In some embodiments, the output device 250 and the input device 255 may be included in a single device, such as interaction device 257, as shown in Figure 2A. Interaction device 257 may include a laptop computing device, desktop computing device, smart phone, tablet, bespoke computing device, or any other suitable computing device, for example. In some embodiments the output device 250 and input device 255 may be included in or comprised by one or more inhabitant devices 294, such as a personal mobile device, including an application, which may include access to the health care monitoring system 270, or in some embodiments cloud services 288. The personal mobile device may also include access to the hub 135. The system 200 may, additionally or alternatively, be configured to determine when the inhabitant 145 is not behaving as expected, such as if the inhabitant 145 is not moving throughout the dwelling 100 as anticipated, or if the inhabitant 145 has failed to perform an action or failed to respond to a prompt. For example, the inhabitant 145 may have moved into the bathroom and not left the bathroom for an amount of time, the amount of time (in some embodiments a predetermined amount of time) being longer than the inhabitant 145 would be expected to be in the bathroom. Responsive to this, the system 200 may be configured to request a response from the inhabitant 145 to ensure that the inhabitant 145 has not become injured, immobilised or otherwise in need of additional assistance. Responsive to determining that the inhabitant 145 may have become injured, the system 200 may be configured to contact one or more predetermined emergency contacts, such as a medical institution, medical professional and / or family member. Behaviours of the system 200, such as prompting the inhabitant 145 to perform an action or to respond to a prompt, determine an adverse health event has occurred, contact a relevant party for assistance, or any other autonomous health monitoring action may be determined by a data processing system (such as hub 135 and / or rules engine 240) configured to receive sensor data. The system 200, due to its automated array of sensors 210 and the hub 135 configured to receive the sensor data and determine actions to be performed, provides for health data to be collected without the need for a trained medical professional to attend the dwelling 100. The system 200 achieves this tracking by collecting real-time data relating to the movement and behaviours of the inhabitant 145 and determining, based on this collected data, one or more courses of action for the inhabitant 145 to take. The system 200 will subsequently prompt the inhabitant 145 to take the determined action, and record that the action has been taken, and / or record a reading from the action, for example an inhabitant 145 weight or blood pressure. By using the collection of sensors 210 in combination with the rules engine 240, the system 200 is capable of recording accurate data, over consistent time intervals, to perform reliable and accurate data tracking and monitoring of the health of the inhabitant 145. Furthermore, the prompts generated by the system 200 include a health self- assessment prompt that is generated in a manner that is sensitive to the context of the inhabitant 145, as tracked by the system 200. The health self-assessment prompt includes two or more predefined questions, delivered by the output device 250, and the system 200 records corresponding answers to these questions, via the input device 255. Further, the system 200 automatically uses the answers (e.g., an answer to a multiple- choice question) to determine one or more further questions, thus monitoring appropriately selected health metrics based on self-assessments from the inhabitant 145, e.g., health metrics based on answers. The dwelling 100, as shown in Figure 1, comprises a plurality of sensors 210, distributed throughout the various rooms or spaces of the dwelling 100. The dwelling 100 may also comprise the hub 135, output device 250 and / or input device 255. The hub 135 may be in communication with the output device 250, input device 255, and / or sensors 210 via one or more wireless personal area networks (WPANs), such as Zigbee, Bluetooth LE, Wi-Fi or any other suitable WPAN. The dwelling 100 further comprises a bathroom 150, passages 155 (otherwise referred to as entrances or exits), passage doors 157, a kitchen 160, bedrooms 165, living area 170, and hallway 175. In some embodiments, the dwelling comprises a different number, type, and / or arrangement of rooms, and each room may be a different size as those depicted in Figure 1. In some embodiments, the dwelling 100 is not a dwelling, and is some other type of physical space with or without defined rooms / walls, such as a warehouse, storage house, a prison, a police station, a fire station, or any other type of physical space. In some embodiments, the dwelling 100 may be different total size and / or shape as shown in Figure 1. It would be apparent to those skilled in the art that the dwelling 100 could take many different sizes, shapes and / or arrangements or any other changes without departing from the scope of the present invention. The sensors 210 distributed throughout the dwelling 100 may comprise, but may not be limited to presence sensors 105, weight sensors 110, bed sensors 115, and / or door sensors 120. The dwelling may also include one or more dynamic lights 125, such as dynamic light 800. The presence sensors 105 are configured to detect the presence or absence of an inhabitant 145 within a predetermined zone, radius or region around the sensor. For example, and as depicted in Figure 1, a particular presence sensor 105 may be configured to determine the presence or absence of the inhabitant 145 within the bedroom 165. Accordingly, the zone that the presence sensor 105 of the bedroom 165 is configured to monitor can be defined by the walls that define the bedroom 165. In some embodiments, more than one presence sensor may be disposed within a contiguous space, for example, and as depicted in Figure 1, the hallway 175 and portals 155 comprise two presence sensors 105. In such an arrangement, the presence sensors 105 may be configured to only detect the presence of inhabitant 145 within a predetermined or preconfigured radius around them, with the sensor itself located in the centre of the sphere defined by the radius in three dimensions. In some embodiments, the detection zone of one particular presence sensor 105 may overlap with the detection zone of another, different presence sensor 105. In some embodiments, the presence sensors 105 are configured to determine, as a binary determination (e.g. "presence detected" or "presence not detected"), the presence of the inhabitant 145 within their respective monitoring zone. According to some embodiments, the presence sensors 105 may be configured to determine a particular location of the inhabitant 145 within their monitoring zone, such as based on a known coordinate reference system. For example, the location of the inhabitant 145 may be determined using X and Y coordinates. In some embodiments, the presence sensors 105 are warm-body-motion-detecting sensors, configured to determine the presence of the inhabitant 145 in a particular room. The system 200 may be configured to correlate the warm-body-detection with which room the inhabitant 145 is within. The weight sensors 110 are configured to determine the weight of an object and / or the inhabitant 145. In some embodiments, the weight sensors 110 may include a set of digital scales that are in communication with hub 135. In some embodiments, the weight sensors 110 may be included in a set of scales. The set of scales may be in wireless communication with the system 200 to communicate the weight of the inhabitant 145 when the inhabitant 145 engages with the scales. In some embodiments, the scales may include further functionality directed to measuring a range of other parameters. For example, the scales may be capable of measuring: body fat (%); fat free body weight; subcutaneous fat (%); visceral fat; body water (%); skeletal muscle (%); muscle mass; bone mass; protein (%); basal metabolic rate (BMR); and / or metabolic age. The bed sensors 115 are configured to monitor the inhabitant 145 when they are lying in the bed 117. The bed sensors 115 may be configured to monitor the presence of the inhabitant 145 in the bed (e.g. "in bed" or "not in bed"), a heart rate of the participant 145, movements of the inhabitant 145 when lying in the bed 117, sleep quality, a respiratory rate (e.g. breaths per minute) and / or a quality of sleep of the inhabitant 145. The door sensors 120 are configured to determine when a door is open, closed and / or when a door moves from an open position to a closed position or from a closed position to an open position. The door sensors 120 may be disposed on any suitable door. Any suitable door may include, but may not be limited to, a portal door 155, such as an entry / exit door or an internal door, a cupboard door (not shown), a cabinet door (not shown), and / or a fridge / freezer door (not shown). In some embodiments, door sensors 120 may be disposed on other objects within the dwelling 100 or attached to the structure of the dwelling 100 that are capable of being opened and / or closed, such as a drawer, a toilet seat / lid, a microwave (or any other type of appliance), or an access panel, for example. The presence sensors 105, weight sensors 110, bed sensors 115, door sensors 120, and / or any other type of sensor 210 may be in wireless communication with the hub 135. The hub 135 is configured to receive determinations from the sensors, determine, based on the sensor determinations one or more events and / or actions, and determining the one or more events or actions may include determining one or more prompts for the inhabitant 145. The hub 135 is additionally or alternatively configured to receive one or more responses from the inhabitant 145. The dwelling 100 may comprise one or more additional types of sensors 210 not shown in Figure 1, including but not limited to, electromagnetic radiation sensors, pressure sensors, temperature sensors, humidity sensors, light sensors, and / or sound sensors. The speaker 140 is in communication with the hub 135 for broadcasting prompts to the inhabitant 145, such as instructions to do a certain task, or questions for the inhabitant 145 to answer. The microphone 142 is in communication with the hub 135 to communicate verbal responses received from the inhabitant 145, such as in response to a prompt. In some embodiments, the microphone 142 is constantly listening for inputs from the inhabitant, such as in the case of an emergency, (e.g. the inhabitant 145 as had an accident and calls for help, or is in distress and requires reassurance). By way of an example, the participant 145 may get up out of bed and walk from the bedroom 165 into the hallways 175. The bed sensor 115 determines that the inhabitant 145 has left the bed, and the presence sensor 105 in the bedroom will register that the inhabitant 145 is no longer in the bedroom 165, and one of the presence sensors 105 disposed in the hallway 175 determines that the inhabitant 145 is now in the hallway. Depending on the needs of the inhabitant 145, the hub 135, responsive to the hallway 175 presence sensors 105, may determine and cause the speaker 140 to output a prompt to the inhabitant 145. In some embodiments, a prompt may not be required when it is determined that the inhabitant has entered the hallway 175. The presence sensors 105 may subsequently determine that the inhabitant 145 has moved into the bathroom 150. Responsive to determining that the inhabitant 145 has entered the bathroom 150, the hub 135 may cause the speaker 140 to output a prompt to remind the inhabitant 145 to weigh themselves using the weight sensor 110 (e.g. the digital scales). The weight sensor 110 may, responsive to determining the weight of the inhabitant 145, may communicate the determined weight to the hub 135. Subsequent to weighing themselves, presence sensors 105 may determine that the inhabitant 145 has moved into the kitchen 160, and the hub 135 may responsively cause speaker 140 to prompt the inhabitant 145 to take their medication. In some embodiments, sometime after causing the medication prompt to be output, the hub 135 may cause a further prompt to be output by speaker 140 requesting a confirmation from the inhabitant 145 that they have taken their medication. In some embodiments, the confirmation may be a spoken confirmation received by microphone 142. In some embodiments, the confirmation may be entered via a computing device, such as a mobile phone, tablet computer, laptop or any other type of suitable computing device. In some embodiments, the hub 135 may comprise one or more interactive elements, such as one or more buttons and / or keys, and / or a touch screen for entering the confirmation. The system 200, as shown in Figure 2A, comprises dwelling 100, network 260, database 265, health care computing system 270, monitoring services 275 and / or user device 280. The dwelling 100, as shown in Figure 2A, comprises the hub 135, the sensors 210, the output device 250, and the input device 255. The hub 135 is a computing device configured to receive sensor data from the sensors 210, process the sensor data and / or perform one or more actions based on the processed sensor data. Additionally or alternatively, the hub 135 is configured to receive events (in the form of sensor data) and process those events into further events (e.g. inferences on something that has occurred within the dwelling 100 based on determined events), or actions, (e.g. processes or outputs to be performed based on the events). The hub 135 may be a computing device, such as a single board computer, a desktop computer, a laptop computer, a smart phone, a tablet computer or a server. According to some embodiments, the hub 135 is a specially constructed and configured single board computing device. In some embodiments, the specially constructed and configured single board computer is based on or includes an Allwinner H3 SoC based board. In some embodiments, the hub 135 may include any other suitable single board computer or small form factor computing hardware. According to some embodiments the Hub 135 comprises a gateway module (not shown) that communicates with the sensors 210, such as via Zigbee protocols, Bluetooth protocol, Internet protocols and / or any other suitable protocols. The hub 135 thereby can receive data from sensors 210, monitor sensor connectivity / battery status and execute actions (e.g. via Health care computing system 270), and other actions such as controlling smart plugs and supported speaker devices in the Dwelling 100. Messages received from the sensors 210 are transformed into consistent structures and stored in the database 242 by the gateway module. According to some embodiments, the gateway module is responsible for Zigbee Coordinator processes, managing Bluetooth connections, polling Internet Protocol / Wi- Fi APIs / devices, operating an MQTT server if required by an IP device, and also executing instructions. Some instructions can be routed to physical devices in the Dwelling 100, others, such as those directed to virtual API device can control the Zigbee processes or send actions to the health care computing system 270. Additionally or alternatively, the hub 135 may include an application processor (not shown) configured to read data from the hub data store 242 and correlate the data with additional information such as which particular sensor 210, sensor type, timing and what other data have already been processed to produce higher-order determinations such as room occupancy, bed presence / absence, shower start / end, sleep start / end and collecting multiple readings into single measurement data. The application processor enables the execution of rules against data as it arrives from the database and / or from the sensors 210. The application processor produces or outputs further data (such as events determined from the received data). The outputs are stored back into hub data store 242 and can be queried over the Network 260 by User Devices 280 and the health care computing system 270, as well as instructions which are stored into the database 242 and the gateway module enables them to be executed. In other words, the gateway module includes the performance of raw data collection / formatting / storage and the execution of instructions. The application processor includes processing of data into derived data that can be used to control the system 200 to perform certain processes as described herein. The application processor enables the receipt of events that have been stored in the hub data store 242, by the gateway module, and the reprocessing of those events with additional metadata, state information from past events, timers, as well as the custom Rules Engine 240 rules, producing additional events that provide value to users when displayed, or instructions, for execution by the gateway module. According to some embodiments, the hub operating system 305, as discussed in relation to Figure 3A, includes the gateway module application processor. In some embodiments, settings and / or configuration data may be included and / or stored in the hub datastore 242 and may be retrieved and executed or applied by the gateway module and / or the application processor. The processor(s) 225 and the memory 230, which stores instructions (e.g. program code), which when executed by the processor(s) 225 causes the system 200 to perform one or more of the methods / processes of the present disclosure, including each of the steps of the processes disclosed herein. Accordingly, these steps can be referred to as “computer-implemented” steps, or “automatic” steps. The processor(s) 225 may comprise one or more microprocessors, central processing units (CPUs), application specific instruction set processors (ASIPs), application specific integrated circuits (ASICs) or other processors capable of reading and executing instruction code. The memory 230 may comprise one or more volatile or non-volatile memory types. For example, the memory 230 may comprise one or more of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM) or flash memory. The memory 230 is configured to store program code accessible by the processor(s) 230. The program code comprises executable program code modules. In other words, the memory 230 is configured to store executable code modules configured to be executable by the processor(s) 225. The executable code modules, when executed by the processor(s) 225 cause the system 200 to perform certain functionality, as described herein. For example, memory 230 may comprise sensor module 235 and / or rules engine 240. The sensor module 235 is configured to receive or otherwise handle the received data from the sensors 210. The sensor module 235 may be configured to receive the sensor data and communicate the sensor data to one or more other modules or components of the hub 135, such as the rules engine 240. According to some embodiments, the sensor module 235 is configured to interface or otherwise handle one or more of the Medium Access Control (MAC), Network (NWK) and Application Support Sub-layer (APS) layers of the data communication framework and communicates the subsequent application framework (AF) frames to the one or more other components of the hub 135 for one or more purposes or processes, for example for decoding and / or determinations about the inhabitant and / or the dwelling 100. The AF is included in the Zigbee standard and may be used by the system 200 for communicating between the one or more sensors 210 and / or the output device 250 or the input device 255. The AF layer deals with the final logical routing of sensor data such that the hub 135 can start to transform the data into information. According to some embodiments, the sensor module 235 includes at least part of the AF layer logic, or functionality thereof. In some embodiments, the communications interface 245 may include part of the AF layer logic. The event module 237 is configured to determine the occurrence of one or more events based on the received sensor data. Examples of events that may be determined include, but are not limited to: the inhabitant 145 entering or leaving a room / the dwelling 100; the inhabitant 145 interacting with a device within the home, the device comprising a type of sensor (e.g. getting into or out of bed, opening / closing a door / drawer, standing on a set of scales, etc.), or any other type of suitable event. The event module 237 may be configured to communicate the one or more events to the rules engine 240. The rules engine 240 is configured to receive one or more events determined by event module 237 and / or sensor data collected by the sensors 210. The rules engine 240 is configured to process and interpret the events and / or sensor data to determine one or more further events or actions to be performed by the system 200. The one or more actions may include communicating with the inhabitant 145, such as via the output device 250. The one or more actions may include communicating with the health care computing system 270, the monitoring services 275 and / or the user device 280. The one or more actions may also include waiting for a response from the inhabitant 145. The further events may be determinations that something has occurred based on already determined events, for example, that the inhabitant 145 has left the bedroom because they have entered the kitchen. The rules engine 240 applies the rules to the events and / or sensor data to arrive at one or more actions by filtering through potential outputs (actions) based on assessing one or more sensor data or events against one or more predetermined criteria. According to some embodiments, the rules engine 240 includes a custom Domain Specific Language (DSL) for executing custom rules given as an expression applied to each event and a corresponding set of targets, (a target may include generate an alert, and / or generate a further event, for example). The targets actioned by rule engine can include sending messages to in-dwelling speakers, controlling smart plugs / lights or opening / closing alerts / pathways. The pathways can then progress by contacting different contacts through SMS / email / notifications / phone calls or escalating to external services. The custom language (DSL) used by the Rule Engine 240 provides data types, Boolean logic operations, value comparisons, access to current-event properties, time and state helper functions and prior-event property tracking helper functions. Additionally or alternatively the custom DSL enables the provision of rules that can be simple with deceptively advanced capabilities through the use of complex expressions that can be applied to the events, wherein the events can be one or more of derived from sensor data, generated by state machines / application logic, system state changes and / or other rules. The targets actioned by rule engine can involve sending messages to in-dwelling speakers, controlling smart plugs / lights or opening / closing alerts / pathways. The pathways can then progress by contacting different contacts through SMS / email / notifications / phone calls or escalating to external services. In some embodiments, a user of the system 200 may define their own rules and / or expressions to tailor the functionalities and / or actions of the system 200 to their particular use case. A user of the system 200 may include the inhabitant 145, a carer for the inhabitant 145, a family member or friend of the inhabitant 145 and / or a medical professional or allied health professional associated with the inhabitant 145. In some embodiments, an administrator of the system may define the rules and / or expressions for the rules engine 240. In some embodiments, the hub 135 and / or rules engine 240 includes a rule and / or expression library from which rules and / or expressions may be selected, or generated, such as selected a plurality of rule and / or expressions elements. The hub data store 242 is configured to store data associated with, used by, and / or generated by the hub 135 (or any components thereof) and / or sensors 210. The hub data store 242 may store sensor data, events, rule sets, rule expressions, rules, expression libraries, configurations and / or settings. The hub data store 242 may store an operating system of the hub 135 and / or other firmware or software configured to enable the hub 135 and / or system 200 to perform its functions. The hub data store 242 may additionally store user and / or inhabitant configurations and / or system settings. In some embodiments the hub 135 is configured to operate independently, for example the hub 135 includes or comprises all software, firmware or otherwise executable processes to interact with the sensors 210, the output device 250, and / or input device 255 to monitor the inhabitant 145. In some embodiments, the hub data store 242 may include one or more of a hard disc drive, a solid state drive, and / or a flash drive and / or SD card. The communications interface 245 facilitates communications between the hub 135 and components within the dwelling 100 or outside of the dwelling 100, for example the health care computing system 270. The communications interface 245 may comprise a combination of network interface hardware and network interface software suitable for establishing, maintaining and facilitating communication over a relevant communication channel and / or protocol. The communications interface 245 may be a wired connect or a wireless connection. The network 260 may include, for example, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, some combination thereof, or so forth. The network 260 may include, for example, one or more of: a wireless network, a wired network, an internet, an intranet, a public network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a public-switched telephone network (PSTN), a cable network, a cellular network, a satellite network, a fibre-optic network, LoRaWan, some combination thereof, other WPANs or so forth. The database 265, which may form part of or be local to the system 200, or may be remote from and accessible to the system 200, for example, via the network 260. The database 265 may be configured to store data associated with the system 200. The database 265 may be a centralised database. The database 265 may be a mutable data structure. The database 265 may be a shared data structure. The database 265 may be a data structure supported by database systems such as one or more of PostgreSQL, MongoDB, and / or ElasticSearch. The database 265 may be configured to store a current state of information or current values associated with various attributes (e.g., “current knowledge”). For example, the database 265 may comprise sensor readings as collected by the sensors 210 and / or as analysed by the hub 135, client / patient data, configuration data, and / or any other type of data that may be generated by, or used by the system 200. In some embodiments, the system 200 does not comprise the database 265. In instances where the system 200 does not comprise the database 265 The health care computing system 270 may be configured to remotely access the hub 135 to perform system configuration, set-up and / or maintenance functions. According to some embodiments, the hub 135, once it is set up, is configured to run independently with little to no interaction with the health care computing system 270. The health care computing system 270 is additionally or alternatively be configured to perform processes related to: inventory management (e.g. tracking of the number, status and / or location of hubs 135 presently operating); authentication, authorization and audit Logging of data of the hub 135 and / or data from the hub data store 242; providing remote access to hub 135, such as from user device 280, such as for a user dashboard and / or mobile application. The monitoring services 275 may be one or more entities configured to monitor or receive updates and / or emergency messages from the hub 135. The monitoring services 275 may receive indications of a status of the inhabitant 145 and / or one or more actions or inactions of the inhabitant 145. In some embodiments, the entities associated with the monitoring services 275 may include 24-hour call centre services such as Safety Link. In some embodiments, the hub 135 may communicate with the monitoring services 275 via API. According to some embodiments, the rules engine 240, based on one or more determined events, may determine that the monitoring services 275 should be contacted. In the instance that the rules engine 240 determines that monitoring services 275 should be contacted, the hub 135 may determine a particular message to communicate, and send that message to the monitoring services 275, such as via an API. The user device 280 may comprise a mobile or handheld computing device such as a smartphone or tablet, a laptop, or a PC, and may in some embodiments, comprise multiple computing devices. In some embodiments, the user device 280 may include a telephone. The user device 280 may be configured to receive messages from the health care computing system 270, such as health alerts related to the inhabitant 145. For example, the hub 135 may determine that the inhabitant 145 is experiencing or has experienced an adverse event, such as not completed a required task (e.g. taking medication), or is having an emergency (e.g. has fallen and cannot get up). The hub 135 may communicate the adverse event determination to the health care computing system 270, and the health care computing device 270 may communicate a notification regarding the adverse event to the user device 280. Additionally or alternatively, the user device 280 may be configured to receive, such as from the health care computing system 270, notification of a positive event, such as the inhabitant 145 successfully taking their medication, or any other such monitored activity. According to some embodiments, when the user device 280 is a telephone or a device that includes voice call functionalities, the hub 135 may generate an artificial voice message, and communicate that artificial voice message via a voice call to the user device 280. In some embodiments, the hub 135 communicates directly with the monitoring services 275 and / or user device 280 via network 260 and may not be required to first communicate with the health care computing system 270. In some embodiments, the user device 280 can be configured to communicate based on the particular needs or abilities of a specific user. For example, the user device 280 can be configured to communicate via text for user that are hard of hearing, or via vox if the user cannot read text easily. Figure 2B is a block diagram of a different embodiment of the system 200 as shown in Figure 2A. The system 200 as shown in Figure 2B may comprise any and all of the same functionalities as the system 200 depicted in Figure 2A. The skilled person would understand that there may be many modifications made to the system 200 of Figure 2A or Figure 2B without departing from the underlying principles of the invention. The system 200, and specifically the processor(s) 225 in operable combination with the memory 230, may be configured to implement a process for monitoring a subject. The computer-implemented (e.g. implemented by the processor(s) 225 in operable combination with the memory 230) process for monitoring a subject may include the steps (e.g. process steps in the form of computer implementable program code) of: receiving, from one or more of a plurality of sensors configured to sense the subject, signals representing physical properties of the subject; processing at least some of the received signals to infer one or more corresponding events of the subject selected from a plurality of predefined events; and in dependence on the one or more inferred events, generating corresponding prompt data to prompt the subject to provide information related to the one or more inferred events; causing the prompt data to be communicated to the subject; and receiving response data representing a response of the subject to the communicated prompt; and processing the response data to determine a health or medical status of the subject. According to another embodiment, the system 200, and specifically the processor(s) 225 in operable combination with the memory 230, may be configured to implement a process for identifying whether a change in a condition of a person has occurred. The computer-implemented process (e.g. implemented by the processor(s) 225 in operable combination with the memory 230) for identifying whether a change in a condition of a person has occurred, may include the steps (e.g. process steps in the form of computer implementable program code) of: determining, using a first sensor of two or more sensors, a presence of the person in a first room, wherein at least two of the two or more sensors are in mutually different rooms of a building; determining, using the first sensor and a second sensor of the two or more sensors, that the person is no longer present in the first room and a presence of the person in the second room; triggering, based on the presence of the person in the second room, an event; responsive to the event being triggered, perform an automated conversation with the person to determine whether a change in a condition of the person has occurred, wherein performing the automated conversation includes: (a) generating a text string, based on the triggered event or a response from the person, wherein the text string is representative of at least a portion of a spoken conversation with the person; (b) generating an audio representation of the candidate text string; (c) outputting the audio representation so as to be heard by the person; (d) determining the response from the person wherein the response is indicative of a current condition of the person; (e) based on the response from the person, performing steps (a) through (d) again, or determining that a conversation termination point has been reached; and responsive to determining that a conversation termination point has been reached, determining based on one or more of the generated text strings, and one or more determined responses, whether the condition of the person has changed. Figure 3A is a schematic diagram of the architecture 300 for collecting sensor data and communicating said sensor data to the hub 135. As shown in figure 3A, sensor data 370 (sometimes described as events) are recorded by the sensor devices. The sensor devices may include Bluetooth devices 315, Zigbee devices 330, Wi-Fi devices 345 and / or API devices 360. Sensor data may include data that is capable of being captured according to one or more device capabilities. For example BT device capabilities 320 may include blood pressure data collection, battery data (e.g. battery status data) collection, time data collection, weight data collection, medication data collection and / or any other type of relevant sensor data. The Zigbee device capabilities 335 may include motion sensing data collection, battery data collection, and / or any other relevant sensor data. The Wi-Fi device capabilities 350 may include: fall & wandering prevention; heart & breathing rates; heart rate; Heart Rate Variability (HRV) (change in time intervals between heart beats - indicator overall health and fitness); recovery data (difference between morning and evening HRV values); breathing rate; sleep classes (type of sleep e.g. Deep sleep, REM, etc.); sleep score; resting heart rate; Autonomic Nervous System Balance; movement activity, tossing & turning (restlessness); XYZ location of occupant in room; fall detection state; weather temperature / condition; and / or GPS location. According to some embodiments, the hub operating system 305 additionally includes network link management, OS updating functions, container management, remote access tunnelling, web servers access / management, authentication and authorisation functions and any other relevant functionalities of an operating system (e.g. Linux, or any other suitable operating system) required for the described functionalities to be performed. In some embodiments, some API devices 360 and / or some API device capabilities 365 may be included in the hub operating system 305. In some embodiments, some API devices 360 and / or some API device capabilities 365 may be partially included in the hub operating system 305 and partially included in other one or more components of system 200, and / or one or more components external to system 200. In some embodiments, some API devices 360 and / or some API device capabilities 365 may be entirely separate to the hub operating system 305 and entirely included in other one or more components of system 200, and / or one or more components external to system 200. The API device capabilities 365 may include: hub control data / instructions collection; communicating alerts to or from other components of the system 200, such as healthcare computing system 270, monitoring services 275, and / or user device 280; and / or any other suitable capabilities for components or systems external to the hub 135. In some embodiments API device capabilities 365 may additionally or alternatively include storage of alerts, alert escalations, pushing notifications, making calls, interfacing with an application or dashboard (for example as running on user device 280). According to some embodiments, Zigbee devices 330 include presence sensors, door sensors, vibration sensors, the output device 250, input device 255 or any other compatible or suitable device. In some embodiments, Bluetooth devices 315 include scales, blood pressure monitors, vibration sensors or any other compatible or suitable device. In some embodiments, Wi-Fi devices include fall detection devices or any other compatible or suitable device. The hub 135 receives the sensor data from the sensors 210. The hub operating system 305 may include the Bluetooth subsystem 310, Zigbee subsystem 325, Wi-Fi subsystem 340 and / or API subsystem 355. Each of the subsystems of the hub operating system 305 are configured to communicating with their respective sensors that use the corresponding protocol. The Bluetooth subsystem 310 is configured to communicate with the Bluetooth devices 315 via the Bluetooth protocol. In some embodiments, the Bluetooth subsystem 310 may use any other suitable type of low energy short-range wireless communication protocol, and it communicates with sensors using the corresponding protocol as necessary. The Zigbee subsystem 325 is configured to communicate to Zigbee devices 330 via the Zigbee protocol. Zigbee is a radio communications standard or protocol that generally operates at lower data transmission rates but has larger range and longer battery life compared to other short wave radio protocols such as Bluetooth. According to some embodiments, the Zigbee subsystem 325 and / or Zigbee devices 330 may be semi- active (passive), in that they do not always broadcast and / or communicate. In some embodiments, the Zigbee components of the system 200 may communicate on a predefined communication schedule. According to some embodiments, the Zigbee devices 330 are monitored using a contract system. The contract system may include the Zigbee devices 330 are contractually obligated to provide updates on certain data points (e.g. the temperature in the room) or to perform certain operations (check-in for polling information, or request more data) at a certain intervals. Each Zigbee device 330 may include or have their own contract. A passive contract relates to data communications or transmissions that occur automatically, such as on a predefined schedule based on the occurrence of one or more triggers. Active checks occur in addition to passive contracts, for example if it is determined that a device may have malfunctioned, or if specific information is needed to determine if an action is required. The Zigbee subsystem 325 is configured to expose low level signals necessary for indication of data requests. If the passive contract is not met an active check of the sensor is performed. Active check referring to communication from the Hub to the sensor. Active checks also allow for sensor configuration to be restored should the sensor be reset or otherwise enter a fault condition. The Zigbee devices 330, according to their passive contracts required to make data requests at set intervals to the hub 135. If a Zigbee device 330 is making data requests at the expected interval / time (or close to) it can be reasonably asserted that the Zigbee device 330 is online. A Zigbee device 330 not making the appropriate data requests, but who has previously made those requests is either: a) Failing (needs to be detected); b) suffering from a poor connection (needs to be detected); or c) has changed parents to connect to a Zigbee router (ZR). To detect c), an active check can be performed on contract breach. Zigbee Routers (ZR) are powered Zigbee Devices, sometime referred to as "full-function devices". Battery powered end devices / reduced function devices (e.g. sensors 210, output device 250 and / or input device 255) can use a ZR as their parent (the target of their data request polling messages), to spread the network load around and expand the coverage area of the wireless network. ZRs may be placed throughout the dwelling 100 to establish and maintain a reliable communication network across the system 200. According to some embodiments, within the system 200, each device, whether it be a Bluetooth device 315, Zigbee device 330, Wi-Fi devices 345 and / or API devices 360, may have a digital device model, the digital device model representing the device and its attributes and / or capabilities within the system 200. The digital device model may include the device type, the data that can be collected by the device, the device's contract and / or any other relevant device information. For example, if a device (e.g. a sensor) supports temperature monitoring, a contract can be defined that will: d) ask the sensor to report the temperature every 30 minutes, or if the temperature changes by 1 degree (but never any more than once per 5 minutes); e) if a temperature is not received within a certain timeframe (e.g. 45 minutes), sometimes referred to as a pass check, or a passive check-in, then it can be inferred that the device or sensor may be malfunctioning; f) if a device or sensor is determined to maybe have malfunctioned, an appropriate response can be defined, such as cause the device / sensor to try to report again; and g) depending on the result of the instruction, it can be confirmed, by active check, whether the sensor is functioning properly and pass / fail the device / sensor appropriately. Contracts can be fine-tuned to each sensor / device to ensure appropriate performance of the system 200. Contracts can be fine-tuned based on attributes such as observed jitter and variations of the device / sensor and / or the expected power consumption that may be caused by running active checks. Generally, passive check costs far less energy from devices / device batteries than what an active check would cost. So correctly defined contracts can lead to improved system efficiencies. The system 200 is configured to minimise polling (how many time communications is established and data exchanged) to maximise battery life while maintaining communication reliability. According to some embodiment the hub 135 processes the sensor data / event using a series of looping Finite State Machines (FSMs). Every instruction / action / alert is built from modules contained within the hub operating system 305. The hub operating system 305 receive sensor data / events and generates further events, which are in turn processed by the hub operating system 305. For example, when an inhabitant 145 enters a room the following sequence of processes events / steps may occur: 1) a motion event is taken in by room confirm machine to confirm a human presence in that room through timers and heuristics; 2) a room confirm machine announces a confirmed room as an event; and 3) The confirm room event is taken in by a room tracker machine to announce an occupant is in that room. The hub operating system 305 is configured to communicate instructions 375 to the various devices of the system 200. The hub operating system 305 may generate an active check message and communicate that message to the various devices via the relevant subsystem. In some embodiments, the active check message may be configured to request data or a response from the devices. In some embodiments, the hub operating system 305, based on the received sensor data, may determine that a message, data or instructions should be communicated to one or more of the API devices. In this instance, the API subsystem 355 may determine an API message and subsequently communicate that message to the relevant API device. Figure 3B is a schematic diagram of a different embodiment of the architecture 300 as shown in Figure 3A. The architecture 300 as shown in Figure 3B may comprise any and all of the same functionalities as the architecture 300 depicted in Figure 3A. The skilled person would understand that there may be many modifications made to the architecture 300 of Figure 3A or Figure 3B without departing from the underlying principles of the invention. The hub 135, as shown in Figure 4, comprises body 405 and antenna 410. Body 405 comprises or otherwise houses computing hardware storing executable software and / or firmware, such as shown in Figure 2A. Antenna 410 may be configured to communicate with the sensor(s) 210, output device 250, and / or input device 255 via wireless communication protocol. In some embodiments, the antenna 410 may be used to communicate with the health care computing system 270, such as via the network 260. In some embodiments antenna 410 may be an internal antenna, and may not extend out from body 405. The presence sensor 105, as shown in Figure 5, may comprise presence sensor body 505 and sensor element 510. The sensor body 505 houses one or more computing components that enable the presence sensor 105 to function, such as recording and communicating sensor information determined by the sensor element 510 to the hub 135. The sensor element 510 may be configured to determine the movement and / or presence of the inhabitant 145. In some embodiments, the presence sensor 105 may be a commercially available presence sensor such as the SONOFF Zigbee Human Presence Sensor, or any other suitable presence sensor. The bed sensor 115, as shown in Figure 6, comprises a bed portion 605 and a computing device 610. The bed portion 605 may be disposed on, in or under the bedclothes or mattress, for example, laid across the mattress with the bedclothes laid over top or laid under the mattress between the mattress and the floor or the mattress and a bed frame. The computing device 610 may be configured to receive and interpret signals from the bed portion 605, such as pressure, heat and / or electrical impulses to determine one or more attributes of the inhabitant 145. The computing device may also be configured to communicate these attributes to the hub 135. The door sensor 120, as shown in Figure 7, comprises first element 705 and second element 710. The first element 705 may, be mounted on a door frame, a fixed portion of a cabinet, or the body of a fridge, for example. The second element 710 may be mounted to an internal / external door, a cabinet door or a fridge door, for example. When a door is closed, the first element 705 and the second element 710 may be caused to be in close proximity with each other. The first element 705 or the second element 710 is configured to detect when it is in close proximity with the other corresponding element, and upon detecting that the elements are in close proximity a "door closed" indication may be determined. Similarly, when the first element 705 and the second element 710 determine that they are not in close proximity, such as when the door is not closed, or not sufficiently closed, a "door open" indication may be determined. The first element 705 or the second element 710 may communicate the "door open" or "door closed" determination to the hub 135. The dynamic light 800, as shown in Figure 8, is configured to turn on and off depending on the location or position of the inhabitant 145, and / or other factors, such as the time of day, or the like. For example, the dynamic light may be configured to turn on when the inhabitant 145 enters a room that the dynamic light is in, and turn off when the inhabitant 145 leaves that room. In another example, the dynamic light 145 may be configured to turn on at a certain time and turn off at a certain time. The output device 250, as shown in Figure 9, may be configured to output audio messages to the inhabitant 145. For example, the hub 135 may determine that an audio message action is required and communicate an audio message for playing through the output device 250. Figure 10 is a process flow of a method 1000 for tracking the inhabitant's 145 health status. In some embodiments, the method 1000 includes tracking an inhabitant's 145 movements throughout the dwelling 100. The method 1000 may be performed at least partially by the system 200 (Figure 2A), in an environment similar to that of the dwelling 100 (Figure 1). The method 1000 should be understood to be an example of tracking an inhabitant's 145 health status, and the process steps may be in a different order, or be different process steps, such as any other step or functionality as described herein. According to the method 1000, at 1005, the inhabitant 145 gets out of bed 117 and leaves the bedroom 165. The system 200 at 1010, (e.g. bed sensor 115 and / or presence sensor(s) 105), detects motion. The system 200, based on this detected motion determines that the inhabitant 145 has gotten out of bed 117 and / or left the bedroom. Accordingly, the system 200 (e.g. the hub 135), at 1015 determines that the appropriate action is to continue tracking the inhabitant (Appendix II lines 37-41). At 1020, the inhabitant 145 enters the bathroom 150 (Appendix II lines 37-41), and this is detected at 1025 (e.g. by a presence senor 105 in the bathroom detecting motion). The system 200 (e.g. the hub 135) at 1030 determines that the appropriate action is to prompt the inhabitant 145 to weigh themselves. As part of this action, the hub 135 may cause the output device 250 to communicate a message to the inhabitant 145, such as a text message or a verbal message. The inhabitant 145 performs the action and the system 200 (e.g. the hub via the input device 255) records the inhabitant data 1035. In some embodiments, the inhabitant 145 may communicate their weight to the system 200 such as via verbal instructions or a text input. In some embodiments, the scales may communicate the inhabitant weight data directly to the hub 135, such as via Zigbee, Wi-Fi or Bluetooth protocols. At 1040, the inhabitant 145 leaves the bathroom and enters the kitchen. The inhabitant's movement are detected by the presence sensors 105 at 1045. The system 200 records the movement and determines the next action to be taken (Appendix II lines 37-41). At 1050, the system 200 prompts the inhabitant 145 to take their medications, for example via a spoken prompt or a text message. The system 200, at 1055, records that the inhabitant 145 has or hasn't taken their medications. In some embodiments, the inhabitant 145 may communicate that that have or have not taken their medication to the system 200 such as via verbal instructions or a text input. In some embodiments, a medication dispensing device may communicate the medication taking data to the hub 135, such as via Zigbee, Wi-Fi or Bluetooth protocols. At 1060, the inhabitant 145 leaves the kitchen and enters the living room. The system 200 detects this movement, at 1065, using the presence sensors 105 and log this event (Appendix II lines 38-41). The system 200, at 1070, prompts the inhabitant 145 to perform a self-assessment. A self-assessment, according to some embodiments, may include the inhabitant 145 reporting on one or more aspects of their health, and / or how they are feeling (emotionally, cognitively and / or physically). In some embodiments, the inhabitant 145 may communicate their self-assessment to the system 200 such as via verbal instructions or a text input. In some embodiments, the verbal instructions may include a voice-based survey performed via the user device 280 and / or the hub 135 and input device 255. The system 200, as shown in Appendix II, may be capable of tracking the inhabitant 145 throughout the dwelling 100 across various movement circumstances. For Example, the system may be able to ignore movements or activities or generally sensor detections in rooms that are not the room the inhabitant 145 is in (Appendix II lines 1-10). The system may be further configured to ignore events such as the inhabitant 145 passing close to the doorway of a room, but not entering said room (Appendix II lines 14-19). Figure 11 is a process flow diagram of a method 1100 for tracking a health status of an inhabitant 145. In some embodiments, the method 1100 includes detecting a fall status of the inhabitant 145 using a sensor configured for detecting the chest of the inhabitant 145, for example whether the inhabitant’s chest is or is not at a particular height (also referred to as a chest sensor). The chest sensor may include a presence sensor (such as a passive infrared sensor (PIR)) that is placed at approximately chest height within a room (e.g. about 1.2m from the floor, but can vary based on the height and / or posture of the inhabitant 145). At 1105, the system 200 begins detection of the inhabitant 145 and / or the dwelling 100 in general. Beginning detection may include the system 200 coming online. Beginning detection may include detecting the inhabitant 145 after a period of inactivity within the dwelling 145, such as in the morning after the inhabitant 145 has been asleep, or while the inhabitant 145 has been seated for an extended period of time, such as when reading or watching television. At 1110, the system 200 (such as using a finite state machine) set's a status of the inhabitant as "exit". A status of "exit" may include detecting that the inhabitant 145 has left a room that they have been in. At 1115, the inhabitant 145 enters a monitored room. At 1120, the system 200 sets the chest sensor status to "inactive" (Appendix I lines 1-3). This may be performed so that any previous detections of the chest sensor, or data received from the chest sensor, are not inadvertently included in this current instance of room occupation by the inhabitant 145. At 1125, the system 200, such as using the chest sensor, detects a sufficient amount of activity to determine that the inhabitant 145 is present and moving around. Response to 1125, the system 200, at 1130, sets the chest sensor status to "active" and continues to monitor the chest sensor (Appendix I lines 5-7). At 1135, the system 200, such as via the chest sensor, detects that activity of the inhabitant 145 has stopped (or otherwise that inactivity has occurred). Responsive to 1135, the system 200, at 1140 begins an inactivity timer (Appendix I lines 9-21). Subsequent to detecting that inactivity has occurred and beginning the inactivity timer, the system 200 may redetect movement by the inhabitant 145 (e.g. via the chest sensor). This will trigger the system to set the chest sensor status as active at 1130 and begin the monitoring process again. In some circumstances, the inactivity timer threshold passes, at 1155, and responsively at 1160, the system 200 determines that the inhabitant 145 has fallen. According to some embodiments, the system 200 may select one or more predefined alert messages based on events determined from sensor data, determined predefined actions and / or a response to a prompt from the inhabitant 145. The alert message may then be communicated to one or more of the monitoring services 275, health care computing system 270 and / or user device 280. In some embodiments, additionally or alternatively, the system 200 is configured to select one from one or more alert prompts, subsequent to selecting the alert message, and output the selected alert prompt via the one or more output devices 250. The system 200 may be configured to perform the selection, and communication of alert messages and / or alert prompts based on the determination of any suitable event where an emergency is expected to be occurring or have occurred. Figure 12 is a process flow diagram of a method 1200 for tracking the health status of an inhabitant 145. In some embodiments the method 1200 includes detecting when the inhabitant 145 is having a shower. The method 1200 may include one or more presence sensors 105, temperature sensors and / or humidity sensors. At 1205, the system 200 waits for the inhabitant 145 to enter the shower. At this point, the system 200 is considered to be in a "waiting for next event" state. This state may be determined by the detection of activity in other areas of the dwelling 100, or by the detection of inactivity in the shower area. At 1210, presence sensors 105 detect motion in the shower area, and the system 200, at 1215, sets the detection status as active. In some instances, the inhabitant may enter / visit the bathroom without engaging in a shower. Whether the inhabitant engages in a shower is determined based on the detected temperature and / or humidity. If the detected temperature and / or humidity is below a predetermined, and / or calculated threshold, the system 200 determines that no shower has started. In this such instance, the process flow 1200 returns to 1205, wherein it waits for an event to occur. The system 200 may additionally or alternatively detect a rate of change of temperature and / or humidity to determine whether the inhabitant is engaging in a shower. At 1220, temperature and / or humidity sensors determine a peak temperature and / or humidity. Responsive to detecting the peak temperature and / or humidity, the system 200 at 1125 creates a shower start event 1225. The system 200 will continue to monitor the shower activity until, at 1230, the system 200 determines that inactivity in the shower area has continued for a certain amount of time. Responsive to determining that inactivity in the shower area has continued for a certain amount of time, the system 200 will create a shower end event. Figure 13 is a process flow diagram of a method 1300 for tracing an inhabitant's 145 health status. According to some embodiments the method 1300 includes generating and outputting spoken commands and / or comments for interacting with the inhabitant 145. The method 1300 may include the output device 250, wherein the output device includes a speaker for outputting sound. At 1305, the hub 135 determines that the next action to be performed (based on received sensor data) is to output a message to the inhabitant 145. Responsive to determining that a spoken message should be communicated to the inhabitant 145, the hub 135 at 1310 communicates a set of message parts to the output device 250.The set of message parts may include fragments of the message to be output, which can be rearranged and / or synthesised, or stored and played by the output device 250. Handling messages in this way is helpful for low energy devices as it does not require the use of high capacity therefore high energy) communication protocols. The output device 250, at 1315, receives the message parts and determines and / or generates the spoken message for playing to the inhabitant 145. The message may include: greetings; weather information; date, event, appointment and / or calendar reminders; reminders to drink water; reminders to move around during the day; reminders to close doors when going to bed; reminders to take medication; reminders to contact certain people or third parties; or any other suitable information derived by or related to the system 200. Subsequently, at 1320, the output device communicates a message ID to the hub 135. The hub 135 at 1325 checks the message to ensure that it is correct, and then communicates a play command to output device 250. Responsive to receiving the play command, the output device 250 at 1330, plays the message to the inhabitant 145. At 1335, the action is marked as completed. Figure 14 is a process flow diagram of a method 1400 of tracking an inhabitant's 145 health status. According to some embodiments, the method 1400 may include a medication taking interaction flow that includes interacting with the inhabitant 145 such as providing prompts and receiving user responses. At 1401, the system 200 is waiting to detect a trigger to track the inhabitant's 145 health status. At 1405, the system 200 may include or have access to a medication database 1405. The medication database 1405 may include a type and number and frequency of a medication that the inhabitant 145 is taking or should take. The system 200 may use the data stored in the medication database 1405 to determine actions for the system 200 to take, for example, prompting the inhabitant 145 to take said medication. Subsequent to a determination, for example based on data received or retrieved from the medication database 1405, that the inhabitant 145 should or needs to take a medication, at 1410, the system 200 detects that the inhabitant 145 has walked into a designated medication room. According to some embodiments, any room may be defined as a medication room. The system 200, for example using the presence sensors 105, detects the inhabitant 145 has entered the medication room, and prepares, as per 1415, a voice message (such as using the method 1300) to prompt the inhabitant 145 to take their medication. At 1420, the system 200, such as via the output device 250, plays the "take medication" prompt. According to some embodiments, the inhabitant 145 may not have a medication to take or, the system 200 determines that the inhabitant 145 has already taken their medication. In this instance, the system 200 may not perform any actions. As shown in Figure 14, the system 200, subsequent to playing the "take medication prompt" listens for a response. The inhabitant 145 may respond verbally with a confirmation that they have taken their medication, or an indication that they have not. According to some embodiments, the inhabitant's 145 response may be in the form of selecting an option from an interactive menu (e.g. "yes" or "no"). Responsive to the inhabitant 145 indicating that they have not successfully taken their medications, the system 200 at 1425, may determine a "medication concern" prompt and communicate the prompt to the inhabitant. The medication concern prompt may include a question asking whether the inhabitant 145 has a question or is generally worried about the medication they should take. The system 200 will subsequently listen for a response to the "medication concern" prompt. Responsive to the inhabitant 145 indicating that they do not have a concern about their medication, the system 200, at 1430 will generate and play a "non-compliance" prompt. A “non-compliance” prompt may include an invitation for the inhabitant 145 to explain their medication concern, or why they have not taken their medication, such as trouble swallowing, or indication of an adverse side effect of taking the medication (e.g. stomach sickness, dizziness, etc.). Responsive to the inhabitant 145 indicating that they do have a concern about their medications, the system 200 will generate and output a "concern explanation" prompt. The "concern explanation" prompt may include an invitation to express any worries that the inhabitant 145 may have about their medications. The system 200, at 1440, records the inhabitant's 145 response to the "non-compliance" prompt or the "concern explanation" prompt. Once the inhabitant 145 has finished giving their response to either of the prompts of 1430 or 1435, for example after a termination phrase or the system 200 determining that the inhabitant 145 has stopped speaking, the system 200 will output a "call ended" prompt, indicating that the system 200 has finished its interaction with the inhabitant 145. The call is then ended at 1450, and an emergency contact is contacted at 1455. For example, at 1455, the system 200 may contact the monitoring services 275, health care computing system 270 and / or user device 280. If the inhabitant 145 responds that they have taken their medication after receiving the "take medication" prompt at 1420, the system 200 dispenses the medication at 1460. In some embodiments, the method 1400 may not include a medication dispensing step, and the inhabitant 145 may take out their own medication from a box, prefilled blister pack or any other suitable medication storage device. After dispensing the medication, or a predetermined amount of time after outputting the "take medication" prompt, the system, at 1465, will output a "medication taken?" prompt, and listens for the inhabitant's response. If the inhabitant 145 responds that they have not taken the medication, then the method 1400 moves to 1425, and progresses through the associated steps as described above. If the inhabitant 145 responds that they have taken their medications, the system 200, at 1485 determines whether extra or additional medications are required to be taken. According to some embodiments, determining if extra medications are required may include determining that more medications should be taken immediately, and / or later on, such as when an inhabitant 145 takes morning, noon and / or evening medications. To determine whether the inhabitant 145 should take extra medications may include the system 200 querying the medication database 1405. If the system 200 determines that extra medication should be taken, the system 200, at 1490, will output the "further medication instruction". After a predetermined amount of time, or after a device has indicated that medications have been dispensed, the system 200 will output the "medication taken" re-prompt and listen for a response. If the inhabitant 145 responds that they have not taken the medication, then the method 1400 moves to 1425, and progresses through the associated steps as described above. If the inhabitant 145 responds that they have taken the extra medication, the system 200 ends the call at 1475, and records a successful medication event at 1480. If the system 200 determines that no extra medication needs to be taken at 1485, the system 200 ends the call at 1475, and records a successful medication event at 1480. In the preceding description of method 1400, it should be understood that the prompts presented to the inhabitant 145 by the system 200 may not be in the form of a verbal prompt. In some embodiments the prompts may be a text-based prompt, such as being displayed on a display screen located in the medication room, or displayed as a notification alert on a smart phone, desktop computer, laptop computer, smart television, smart watch or any other suitable device. Further, the responses by the inhabitant, in some embodiments may not be verbal, but may be a text input or a selection from a graphical user interface, for via a display screen located in the medication room, or displayed on a smart phone, or smart watch. Figure 15 is a process flow diagram of a process 1500, performed, for example by system 200, of identifying whether a change in a condition of a person has occurred or not. At 1510, the system 200, for example the hub 135, determines a presence of a person in a first room. According to some embodiments, the system 200 may be specifically configured to track a subject, such as a person, within a building that includes two or more rooms. Specifically, the system 200 may be configured to determine when a person is not in a room. Additionally or alternatively the system 200 may determine or detect when a person enters a room, or otherwise that an occupation state of a room has changed from an unoccupied state to an occupied state. Determining the presence of a person in the first room may include detecting entry, by a person, into the room. Determining the presence of a person in the first room may additionally or alternatively include actively, continuously or otherwise persistently detecting the presence of the person in the room. At 1515, the system 200, for example the hub 135, determines / detects that the person is no longer present in the first room and determines a presence of the person in the second room. Determining / detecting that the person is no longer present in the first room may include detecting that the person has exited the room. Additionally or alternatively, determining / detecting that the person is no longer present in the first room may include no longer detecting a presence of the person in the first room. In some embodiments, determining / detecting that the person is no longer present in the first room may include determining a presence of the person in the second room, as the person cannot be present in two rooms at once. Determining the presence of a person in the second room may include detecting entry, by the person, into the room. Determining the presence of a person in the second room may additionally or alternatively include actively, continuously or otherwise persistently detecting the presence of the person in the room. Determining the presence of a person in the second room may include determining / detecting that the person is no longer in the first room. According to the present embodiments, determining / detecting the presence of the person in the first room and the second room may be performed by one or more sensors 210 disposed in the respective first room and second room. A sensor 210 disposed in the first room may detect, via any suitable means, the presence of the person in the first room. Another sensor 210 disposed in the second room, different from the sensor 210 of the first room, may detect, via any suitable means, the presence of the person in the second room. According to some embodiments, the system 200, determines / detects the presence of the person in the first or second room without performing optical based image analysis. Without performing optical based image analysis may include, but is not limited to using LiDAR (Light Detection and Ranging) sensors, time of flight sensors, radar sensors, ultrasonic sensors, or any other non-image and / or non-visible light based detection system, device, method or product. In some embodiments, the sensors are not capable of capturing images. At 1520, the system 200, for example the hub 135 triggers an event. Triggering the event, or the event may include a system alert that an action should be taken or that an action will be taken or can be taken. As described above, the system 200 may include one or more rules or rule sets that when satisfied, trigger the system 200 to perform a certain action and / or function. Additionally or alternatively, triggering the event may include determining that one or more criteria have been satisfied. In some embodiments, triggering the event may include a determination and / or detection that the person has moved from the first room to the second room. Triggering the event may further include determining, by the processing device, one or attributes of the first and / or second room and additionally triggering the event based on the one or attributes of the first and / or second room. For example, an attribute of the room may be the purpose and / or function of the room (e.g. kitchen, bedroom, bathroom, living room, etc.). Further, certain changes to the condition of the person may be caused by or otherwise associated with certain rooms in a building. For example, upon the person entering the kitchen (or the room designated as a kitchen), their condition may change to a “medication required condition”. In another example, if a person’s moves from the bedroom to the hallway, and then stays in the hallway for a period of time longer than they would otherwise be expected to be there, their condition may change to “in need of assistance”. In some embodiments, the rooms may additionally, or alternatively include room qualities, such as comfortable (e.g. bedroom, living room, study, or dining room), functional (kitchen, bathroom, laundry), transitional (e.g. hallway, mudroom, or entry way), etc. In a further example, if a person enters a comfortable room, their condition may change to “ready to receive a communication” e.g. an automated conversation or phone call. Additionally or alternatively, triggering event further includes determining one or more of: a time of day; a day of the week; one or more medication schedules of the person; and one or more medical conditions of the person. Triggering the event and subsequently conducting the automated conversation may additionally or alternatively include, determining that the current time of day is an acceptable time of day to have the conversation, that the previous successful daily call occurred before today, that the occupant is home (perhaps even moving about or having recently exited the bathroom), so it creates an alert action (e.g. triggers an event) to conduct the conversation with the person. The one or more text strings generated by system 200 may pertain to the triggered event, or may simply be associated with a daily check-in conversation. In some embodiments and at 1525, responsive to triggering the event, the system 200, for example the hub 135, performs an automated conversation with the person to determine whether a change in a condition of the person has occurred. Alternatively, one or more other components of the system 200 may perform the automated conversation, for example, the monitoring services 275. Performing the automated conversation includes generating a text string, based on the triggered event or a response of the person, wherein the text string is representative of at least a portion of a spoken conversation with the person. In some embodiments, the system 200 generates at least one text string indicative of at least a portion of the conversation to be had with the person. In some embodiments, the system synthesises as many text strings that it can determine in advance of the conversation. Additionally, the system 200 synthesises, into audio samples,, one or more text strings and sometimes all of the presently determined text strings into audio samples, prior to initiating the call. According to some embodiments, generating the text string is further based on one or more of: a time of day; a day of the week; one or more medication schedules of the person; and one or more medical conditions of the person. Performing the automated conversation includes generating, by the system 200, an audio representation of the candidate text string. This is performed using any suitable text to speech system, model, or process. Subsequent to at generating at least one text string, the system 200 outputs the audio representation so as to be heard by the person. Outputting the audio may include outputting the audio via one or more speakers of the system 200. Subsequent to outputting the audio, the person may respond verbally to answer. Upon a verbal response of the person, the system 200 determines a response from the person wherein the response is indicative of a current condition of the person. Determining the response may include the system 200 performing speech recognition over the verbal response. The response is transcribed and stored as values, and the timestamp of the response is stored in association with the transcribed response. In some embodiments, the response is parsed into different categories that are indicative of the type of response, the nature of the response, the condition (or a change thereof) of the person. The categories include, but are not limited to: responses that mean yes, responses that mean no, numeric values or verbatim free-form responses. If the response includes portions such as "what?", "speak up", "pardon", "didn't hear that," or language indicative thereof, the system 200 outputs the presently determined audio representation again. If the response includes portions such as "skip", "not answering that", or language indicative thereof, the system 200 allows the question to go unanswered. If the text string is in the form of a question, then the text string will have an expected answer associated with it. The expected answers may be classified into categories, including a “no answer required” category. Each answer category allows for an acknowledgement statement to be spoken by the person before the system determines whether another text string must be generated, and / or output. Text strings can make reference to responses received in response to previous text strings. Upon successful completion of the conversation, a conversation result with values such as 'wellness-rating: 1' or 'medication-concern: true', 'medication-concern-reason: "ran out"' is stored along with the timestamp-annotated call reconstruction and stored accordingly, such as described above. Based on the response from the person, the system 200 either performs the steps of generating a text string, generating an audio representation, outputting the audio representation and determining the response, or determines that a conversation termination point has been reached. A conversation termination point may include a determination that all or most conversation points that are associated with the triggered event have been output and / or responded to by the person. A conversation termination point may include that the person did not engage in the conversation, e.g., by providing no responses, or by not providing intelligible responses. Responsive to determining that the person did not engage in the conversation, the system 200 may determine another time to attempt the conversation. In the event that multiple conversations are deemed to have failed, then the system 200 may generate an alert that an in-person check-in must be conducted and alert the relevant parties. Once the conversation is concluded (e.g. a conversation termination point has been reached), the raw received response audio is combined with the generated audio from the text strings, to produce a reconstruction of the full call, with timestamps of the person's responses and the values stored against each question stored as the call result. According to some embodiments, the automated conversation may be enabled via a phone call. In such an embodiment, the system 200 detects the triggering of an event (e.g. a scheduled item being due and the occupant being available, or an event of concern) or non-event (e.g. a lack of morning / evening routine) through its normal methods (custom rules, processor modules), creates an alert action and communicates it to a cloud-based alert handling system for processing via an alert pathway. A matching alert pathway processes the alert action and, if configured to do so (via a contact-via-call pathway step), uses a call agenda provided in the alert action and a contact found in either the alert action or resolved through the pathway step configuration to create a call job. The call agenda is a human-readable, human-writable list of textual steps that an agent (person / AI) could use to make a phone call with the call recipient. Call agendas would start with a greeting that states the purpose of the call, some questions, including questions conditional on prior answers, or information that needs to be conveyed, and a farewell. The call process includes validating and preparing the call agenda and target contact, synthesising an opening speech message with a Text-To-Speech (TTS) API service and dialling the call using a Voice Telephony API service. The Voice API will report the status of dialling, and upon successful call establishment, initiate a bi-directional audio stream with the Halley Hotline instance. Audio received through the stream is forwarded to and processed by a Speech-To-Text (Speech Recognition) API, with the transcribed speech integrated into a call state document, which is combined with role and purpose-describing instructions, and processed through a Large Language Model (LLM). The text prediction / continuation / response from the LLM is parsed, with the next-phrase- to-be-spoken extracted, synthesised through the TTS API and played through the audio stream to the human call participant. The parsed text prediction is also used to update the call state document, which can involve recording the answers to questions asked, setting the status of agenda items, recording notes for the next call to the LLM and notes for use in the call summary. The LLM handles the natural language processing required to respond to mis-transcribed audio, requests for repetition or clarification, and mis-hearings on the call recipient's end. The LLM can also request that the call be terminated, which is handled by the Halley Hotline service running the call and communicated to the Telephony API. Once the call is terminated, an LLM is provided with different instructions and the completed call state and call transcript. Its role is to correct any remaining mistranscriptions in the call transcript, assign values / answers to the agenda items based on what was said and noted during the call, and determine whether the call should be flagged as requiring a human-operated call back or immediate attention. This call summary is stored as a call result in the cloud database and is transmitted back to the hub 135 through the existing bidirectional remote access tunnel that the hub 135 establishes with other components of the system 200. The call summary is also processed through alert pathways, where requests for callbacks and attention can be pushed to staff or carer devices. Upon receipt of the call result object, the hub 135 stores it in an internal database as an event and process it as a regular data-bearing event. Custom rules and processor software modules are able to further act on the call result event, such as by creating additional alert actions and timeline entries. The raw call audio is archived, available for playback by dashboard users should they wish to verify the call transcription or interpret additional information captured by the raw audio. In some embodiments audio-native LLMs that can directly interpret audio samples and directly respond with audio samples may be used for the above-described calls / conversations. In some embodiments, self-assessment / regular check-in calls / conversations may be performed. For example, a rule detects that one is due, creates an alert action with the call agenda it was configured with, call is made, call result event arrives, a second rule inspects the data fields of the call result and decides whether to create an alert open action due to concerns reported during the call. The alert action contains the ID of the call result, allowing the dashboard to link them together. The rule engine has control over alert severity, allowing no-concern call results to be visible on dashboards if desired, but filterable by user dashboards and alert pathways. According to some embodiments, the system 200 may not generate and output audio samples to conduct the automated conversation with the person. Additionally, the system 200 may not record and transcribe (transform into text), audio responses by the person. Alternatively, the system may conduct the automated conversation using a text chat, such as via a user device 280 (e.g. a phone, laptop computer, desktop computer, tablet computer, etc.). To conduct the text-based conversation, the system 200 may determine the text strings to be provided to the person in the same way as described above. Similarly, the system 200 may process the responses of the person as described above, except the step of transcribing the audio and / or cleaning the audio / transcribed text is not performed. In the text-based conversation, all other processes that are not associated with the audio aspect of the conversation are performed. In some embodiments, the conversation may be multimodal, occurring via text and audio / speech. For example, the system 200 may output audio samples to the person, but the person may respond using a text-based input. In another example, the system 200 may output text, but the person may respond with speech. It will be understood that the system 200 could utilise numerous different combinations of text and audio to perform the conversation and still achieve at least some of the benefits of the present disclosure. At 1530, the system 200 determines whether a condition of the person has changed or not. Determining whether a condition of the person has changed may include, determining a wellness-rating value. Wellness ratings may include a person supplied self-assessed rating. The wellness rating may include a numeric rating (e.g. 5 / 10). The wellness rating may include a qualitative rating (e.g. “good”, “bad”, “better than yesterday”, etc.). The wellness rating provided by the person may be compared to one or more previous responses. Comparing the provided wellness rating to one or more previous wellness ratings may include determining a trend in wellness of the person. In some embodiments, qualitative responses may be converted into quantitative responses by comparing them to previous responses or with other health data of the person. In some embodiments, the provided wellness rating may be compared to a predetermined threshold. The wellness-rating value may be compared to a predefined threshold to determine whether the persons condition has changed. According to some embodiments, by triggering an event, the system 200 may predetermine a condition of the person. Predefining the condition of the person may include determining that the person must complete a task, such as partaking in an interview, taking medications, weighing themselves, cleaning themselves, leaving the house to attend an appointment, or any other suitable task. Further, determining that the condition of the person has changed may include determining that they have completed the task. Determining that a condition has changed may further include determining one or more further actions to be taken. In some embodiments, subsequent to determining whether the condition of the person has changed, the system 200 may determine an alert action to notify one or more third party, which may include but is not limited to, doctors, nurses, carers or any other type of person who may reasonably be notified. Additionally or alternatively, the system 200 stores one or more of the generated text strings, response audio, transcribed text based on the response audio and any determinations based on the conversation. The system 200 may store this information into fact slots, which can be used by string templating to embed data into reports, or otherwise outputs from the system. The audio portions of the automated conversation may also be played back via a user interface, such as via the monitoring services 275, healthcare monitoring system 270 and / or user device 280. The data stored by the system 200 may include a conversation reference number. According to some embodiments, the results of or components of the automated conversation may be used to determine or otherwise generate a summary report. For example, the system 200 may aggregate the results of or components of one or more automated conversations into a summary report that is indicative of the condition (and changes thereof) of the person’s condition. The summary report may be further augmented using passively collected data (e.g. sleep data, movement data, presence data, or any other behavioural data) to give a more complete picture of the person’s condition. AI could then be used to automatically prepare reports for a human “wellbeing coach,” who would review the data at regular intervals (e.g., monthly or quarterly). That coach would then provide personalised guidance by phone or in person, with the goal of sustaining the person’s independence and wellbeing over time. Figure 16 is a screenshot of a user interface indicating a check-in graphical user interface (GUI) 1600. A user may check-in to the system 200 using the GUI 1600. Additionally or alternatively, the system 200 may be configured to check people in based on proximity, e.g. proximity to the hub 135. The hub 135 may track proximity to a registered user device of a person to be checked-in, for example, using Wi-Fi, Bluetooth, NFC, or any other suitable communication protocol. By way of example, a person, in possession of a user device that is capable of broadcasting using a suitable communication protocol, may approach the dwelling, comprising the system 200 and the hub 135. The hub 135 may detect the user device, and determine a strength of the signal being received via the communications protocol. Once the signal reaches a threshold strength, that is indicative of a degree of proximity of the user device to the hub 135, then the hub 135 may automatically check-in the user to the hub 135, such that the system 200 is aware of their presence, or impending presence in the dwelling. According to some embodiments, approaching the hub 135, for example with the check- in capable client device 280, causes the client device 280 to automatically switch its interface to one that enables the user of the user device 280 to interact with the hub 135 and / or the system 200. Upon approach by the person in possession of the check- in enabled user device 280, the hub 135 may generate an event to cause the system 200 to perform an action. For example, the action may include disarming, deactivating or otherwise stopping certain rules that would cause the system 200 to perform certain actions. Additionally or alternatively, the action may include ceasing statistical data gathering when a carer is present. Additionally or alternatively, the hub 135 may determine when the check-in enabled user device 280 moves away from the hub 135 and re-arm the system 200 to perform the previously deactivated actions. Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention. The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form of suggestion that the prior art forms part of the common general knowledge in Australia. In this specification and the claims that follow, unless stated otherwise, the word "comprise" and its variations, such as "comprises" and "comprising", imply the inclusion of a stated integer, step, or group of integers or steps, but not the exclusion of any other integer or step or group of integers or steps. References in this specification to any prior publication, information derived from any said prior publication, or any known matter are not and should not be taken as an acknowledgement, admission or suggestion that said prior publication, or any information derived from this prior publication or known matter forms part of the common general knowledge in the field of endeavour to which the specification relates. Appendix I Fall detection Pseudocode: case exit (starting state): If enter monitored room: Go to inactive state case inactive: If sufficient activity detected at chest height met: Go to active state case active: If leave room: Go to exit state If not active: Go to timer state case timer: If fall detection time elapsed: Generate fall detection alert If activity on chest detector: Go to active state If exit monitored room: Go to exit state Appendix II Room tracking pseudocode: on room confirm machine sensor inactive event: if the event is for the current room and the event is after the time the inhabitant entered the room: if currently not inactive and this event is for a room other than the one the inhabitant is currently in: return, ignore event if this event is for a different room than the one the inhabitant is currently in and this event is before the time the inhabitant entered the room: return, ignore event if this event is for the current room store the currently inactive time if inactive time predates the room enter time (quick activity, potentially a doorway): get the room that was previously active exit this room enter the previous room return, wait for next event wait for inactive time to pass when inactive time passes: exit any room currently entered enter the next room return, wait for next event on room confirm event: if currently inactive clear inactivity timer if is an event for a room (not leaving the house) and this event is for the room currently occupied: clear any inactivity for the room return, wait for next event if in a room: create an exit event for that room create an enter event for this room and store state return, wait for next event

Claims

The Claims Defining the Invention Are As Follows:

1. A system for monitoring a subject in a physical space, the system including: a plurality of sensors for detecting movements of the subject in the physical space; a data processing system configured to: receive from the sensors signals representing detected movements of the subject in the physical space, process the received signals to determine corresponding movements of the subject in the physical space, and select an action from a plurality of predefined actions, based on the detected movement; and one or more output devices for outputting a prompt based on the selected predefined action for the subject.

2. The system of claim 1, wherein selecting the predefined action includes determining, based on the received signals, one or more events that have occurred, and selecting, based on the one or more events the predefined action.

3. The system of claim 2 wherein the data processing system is situated in the physical space and is configured to receive signals representing the detected movements, determine a movement of the subject, select the predefined action, determine one or more events and output the prompt independent of an external data connection.

4. The system of any one of the preceding claims, wherein the data processing system uses one or more finite state machines to determine or select the predefined action and / or the one or more events.

5. The system of any one of the preceding claims, wherein the data processing system includes a rules engine.

6. The system of any one of the preceding claims, wherein the sensors are not configured to capture images.

7. The system of any one of the preceding claims further including one or more input devices configured to receive a subject response to the outputted prompt, and to send the received subject response to the processing system.

8. The system of claim 7, where the processing system is configured to determine a further action and a further prompt based on the received subject response, for output by the output devices, thus providing two or more questions in the respective prompts for the subject.

9. The system of claim 7 or claim 8, wherein the subject response is recorded and stored in an internal data store of the system.

10. The system of any one of claim 9, wherein subsequent to the subject response being recorded and stored, the subject response is communicated to a third party device.

11. The system of any one of claims 7 to 10, where the one or more input devices include any one or more of: a sound sensor; a smart watch; a keypad; a touch enabled display monitor; a smart television; and mobile computing device.

12. The system claim 7 to 11, where the processing system is further configured to select one from one or more predefined alert messages, based on: the one or more determined events; the selected predefined action; and / or the subject response.

13. The system of claim 12, where the processing system is configured to select one from one or more alert prompts, subsequent to selecting the alert message, and output the selected alert prompt via the one or more output devices.

14. The system of claim 12 or claim 13, wherein the processing system is configured to communicate the selected alert message to one or more emergency contacts that are remote from the physical space.

15. The system of any one of the preceding claims, wherein determining of the movement of the subject in the physical space includes: determining, based on one or more entry / exit sensors, that the subject is currently inside the physical space.

16. The system of any one of the preceding claims, wherein the sensors include two or more of the following types of sensors: bed sensors; seat sensors; latch sensors; door sensors; motion sensors; presence sensors; temperature sensors; step trackers; humidity sensors; noise sensors; fall sensors; light sensors; air quality sensors;fire sensors; smoke sensors; glucometer; panic button; blood pressure sensors; pulse oximeter sensors; heart rate sensors; weight sensors; impact sensors; and GPS trackers.

17. A method of installing a system for monitoring a subject in a physical space, the method including: installing in the physical space, a plurality of sensors for detecting movement of the subject in the physical space; installing in the physical space a data processing system configured to: determine a movement of the subject in the physical space; and select one from two or more predefined actions, based on analysis of the detected movement; configuring one or more output devices for outputting a prompt based on the selected predefined action for the subject.

18. A kit that when assembled provides a system for monitoring a subject in a physical space, the kit including: a plurality of sensors for detecting movement of the subject in the physical space; a data processing system configured to:receive signals representing the detected movement from the sensors; determine a location of the subject in the physical space, and select one from two or more predefined actions, based on analysis of the detected movement; one or more output devices for outputting a prompt based on the selected predefined action for the subject; and instructions that comprise the method according to claim 17. 19.A system for identifying whether a change in a condition of a person has occurred:two or more sensors for detecting a presence of the person, wherein at least two of the two or more sensors are in mutually different rooms of a building; a data processing system configured to: determine, using a first sensor, a presence of the person in a first room; determine, using the first sensor and a second sensor, that the person is no longer present in the first room and a presence of the person in the second room; trigger, based on the presence of the person in the second room, an event; responsive to the event being triggered, perform an automated conversation with the person to determine whether a change in a condition of the person has occurred, wherein performing the automated conversation includes: (a) generating a text string, based on the triggered event or a response from the person, wherein the text string is representative of at least a portion of a spoken conversation with the person; (b) generating an audio representation of the candidate text string; (c) outputting the audio representation so as to be heard by the person; (d) determining the response from the person wherein the response is indicative of a current condition of the person;(e) based on the response from the person, performing steps (a) through (d) again, or determining that a conversation termination point has been reached; and responsive to determining that a conversation termination point has been reached, determining based on one or more of the generated text strings, and one or more determined responses, whether the condition of the person has changed.

20. The system of claim 19, wherein the presence of the person in the first or second room is determined without performing optical based image analysis.

21. The system of claim 19, wherein triggering the event further includes: determining, by the processing device, one or attributes of the first and / or second room; and wherein triggering the alert is further based on the one or attributes of the first and / or second room.

22. The system of claim 19, wherein triggering the event further includes determining one or more of: a time of day; a day of the week; one or more medication schedules of the person; and one or more medical conditions of the person.

23. The system of claim 19, wherein generating the text string is further based on one or more of: a time of day; a day of the week; one or more medication schedules of the person; and one or more medical conditions of the person.

24. The system of claim 19, wherein the data processing system, responsive to the event being triggered, is further configured to determine one or more behavioural aspects of the person; and wherein determining whether the condition of the person has changed or not is further based on the behavioural aspects.

25. The system of claim 24, wherein the data processing system is further configured to generate and output one or more reports indicative of the automated conversation and / or the behavioural aspects of the person.

26. The system of claim 19, wherein detecting the presence of the person in a room includes, determining a period wherein the person is not in a room, detecting when the person enters the room, and continuously detecting the presence of the person while they remain in the room.

27. A computer-implemented process for monitoring a subject, the process including the steps of: receiving, from one or more of a plurality of sensors configured to sense the subject, signals representing physical properties of the subject; processing at least some of the received signals to infer one or more corresponding events of the subject selected from a plurality of predefined events; and in dependence on the one or more inferred events, generating corresponding prompt data to prompt the subject to provide information related to the one or more inferred events; causing the prompt data to be communicated to the subject; and receiving response data representing a response of the subject to the communicated prompt; and processing the response data to determine a health or medical status of the subject.

28. A computer-implemented process for identifying whether a change in a condition of a person has occurred, the process including the steps of:determining, using a first sensor of two or more sensors, a presence of the person in a first room, wherein at least two of the two or more sensors are in mutually different rooms of a building; determining, using the first sensor and a second sensor of the two or more sensors, that the person is no longer present in the first room and a presence of the person in the second room; triggering, based on the presence of the person in the second room, an event; responsive to the event being triggered, perform an automated conversation with the person to determine whether a change in a condition of the person has occurred, wherein performing the automated conversation includes: (a) generating a text string, based on the triggered event or a response from the person, wherein the text string is representative of at least a portion of a spoken conversation with the person; (b) generating an audio representation of the candidate text string; (c) outputting the audio representation so as to be heard by the person; (d) determining the response from the person wherein the response is indicative of a current condition of the person; (e) based on the response from the person, performing steps (a) through (d) again, or determining that a conversation termination point has been reached; and responsive to determining that a conversation termination point has been reached, determining based on one or more of the generated text strings, and one or more determined responses, whether the condition of the person has changed.

Images