Context-aware remote care alert system for patient populations

Abstract

Methods and systems for generating one or more health care alerts for one or more patients are disclosed. Real-time or near real-time measurement data is received from one or more sensors located in a living environment of a senior patient, and is used to generate a status report of the patient. At least one rule pertaining to the patient is identified from an individual rules engine using the measurement data, wherein the identified rule is applied to generate an alert indicator for the patient. At least one rule from a population rules engine pertaining to the patient is identified using the measurement data from the patient and other measurement data from a patient population, and generate a health assessment for the patient. A user interface is generated on a care provider device including at least one of the measurement data, status report, alert indicator, and health assessment of the patient.

Description

CONTEXT-AWARE REMOTE CARE ALERT SYSTEM FOR PATIENT POPULATIONSTECHNICAL FIELD

[0001] This disclosure relates generally to integrated hardware and software methods and systems for enhancing productivity, efficiency, and quality of care for patients, including elderly or disabled people living at home or in residential health care facilities, retirement living facilities, assisted living facilities, nursing or long term care facilities, hospitals, or other clinical or non-clinical settings. This disclosure relates more specifically to inventive methods and systems for generating context-aware care alerts for patient populations, enabling family members and professional caregivers to effectively monitor and care for one or more patients, either remotely or in multiple locations.BACKGROUND

[0002] Older people, like children, often need regular care, particularly as life expectancies increase. Older people also frequently express a desire to age in place in their homes rather than move to a nursing home or elder care facility or community. However, the demand for elderly care outstrips supply in nearly every developed economy. Demographics of developed nations and the pressures on many national health care systems mean that demand for elder care will continue to grow. Currently, 500 million people aged 65+ live in the G20 nations. By 2050, that number is projected to reach over 1 billion. In the United Kingdom, for example, 1.5 million older people have an unmet need for care.

[0003] Despite significant advances in health care technology, senior care continues to present considerable challenges. Caregivers often grapple with substantial workloads, inefficient practices, and the need for continuous senior monitoring, leading to diminished productivity and elevated stress levels. Moreover, the need for constant monitoring of many elderly patients can lead to even greater inefficiencies and gaps in care.

[0004] If productivity of elder care providers remains the same, 60% more care providers will be needed by 2040. Health care systems in many industrialized countries as well as developing nations are often under pressure to focus purely on acute clinical need. This can further increase demand for caregiving services for the elderly, particularly as the available capacity in hospitals and skilled nursing facilities are needed to serve the most acutely ill patients. Conventional face-to-face caregiving for the elderly is labor-intensive, inefficient, and expensive. On the other hand, caregiving staff are often overworked and underpaid, resulting in a caregiving labor sector that is in crisis throughout the developed world. In the United Kingdom, annual care staff turnover is 38%.

[0005] Technology enabled care (TEC) is one way that is being explored to address at least in part the unmet needs for caregiving of the elderly. However, many current TEC products are often complex to install, yet only offer a limited point solution to address one specific facet of caregiving for the elderly (e.g., a call alarm system for an elderly person to summon help after a fall). TEC products often offer a poor user experience and a poor value for the money spent. TEC products also may often come onto the market quickly and either disappear just as quickly, making it difficult for the users of such care products to find support and repair for their products in use. Finally, TEC products may be cumbersome to use, and can be unattractive and stigmatizing for the older people using these devices.

[0006] One recent study, by the Institute of Public Health at the University of Cambridge, concluded that an inability for an elderly person to get up after falling often resulted in the person lying on the floor for a long time, despite the fact that call alarms were installed. Despite an installed alarm system, in 36 out of 37 (97%) of “long lies” the person who fell alone did not use their alarm to summon help. Lying on the floor for a long time is also strongly associated with serious injuries, hospital admissions, and subsequent moves into long term care.

[0007] More caregiving staff is also not the solution, as elderly care is too labor intensive, expensive and inefficient as noted above. Caregivers often have to work with limited and / or incomplete information (often provided by the patient alone, or another caregiver, with no access to the patient’s medical history or other details). Caregivers often provide care to their elderly and / or disabled clients on a fixed and / or limited schedule and do not have a full picture of their patients’ daily activities and health status. This results in caregivers, family members and loved ones, medical professionals, and others involved in the care of an elderly person each having different and incomplete information. As a result, problems are often missed until the situation reaches a crisis or emergency, where the paramedics are called. Alternative solutions to address these problems are needed.SUMMARY

[0008] Systems and methods disclosed herein provide a comprehensive solution that can streamline care tasks, consolidate information from various sources, automate alerts and instructions, optimize caregiver activities, and enhance caregiver collaboration, ultimately aiming to improve the quality of care by enhancing caregiver productivity in senior and other care settings. Sensor technology, software applications, cloud-based platforms, and data analysis tools are utilized to equip caregivers with relevant information, insights, and instructions to deliver efficient, personalized care. This integrated approachemphasizes both improving care outcomes and enhancing caregiver well-being by mitigating workload and stress. The systems and methods described herein are, in some embodiments, personalizable and customizable to particular individual and / or care provider needs both over time and with changing circumstances. While the systems and methods described herein are often described in connection with an elderly patient (i.e., a “senior”), they can be used in connection with any individual (i.e., patient) regardless of age. The systems and methods described herein are used in health care or clinical settings, but may also apply to homes or other care settings where caregivers monitor the health, wellbeing and / or safety of patients, seniors and other individuals receiving care.

[0009] Embodiments of the systems and methods disclosed herein comprise a patient data analytics platform utilized by caregivers that is interconnected with a network of devices, including but not limited to sensors, machines, measurement devices, software applications, data sources, and other entities. The networked devices are strategically located within the senior’s living environment, on seniors, or utilized by caregivers, and communicate data to and from a cloud-based patient data analytics platform. This platform serves as a comprehensive repository, and amasses, processes, and analyzes data to generate insights, alerts, recommendations, and messages for caregivers, seniors, family members, clinicians, and other relevant parties. Furthermore, it enables device operations responsive to the specific needs of the cared-for individuals as well as the requirements of the care coordinators and caregivers. For example, the patient data analytics platform can provide information to some of the devices, enabling them to operate in response to the particular needs of the person being cared for, or the particular requirements of the care coordinator or caregiver. Machine learning algorithms described herein may take input gathered data from the networked devices and provide insights and recommendations to caregivers to improve quality of care. In addition, thepatient data analytics platform includes graphical user interfaces (GUIs) for caregivers, which present information in an easy-to- understand format.

[0010] In one embodiment, methods and systems are disclosed for generating one or more care alerts for one or more patients. Real-time or near real-time measurement data is received from one or more sensors located in a living environment of a first patient of the one or more patients. The real-time or near real-time measurement data from the one or more sensors is used to generate a status report of the first patient. At least one rule pertaining to the first patient is identified from an individual rules engine using the real-time or near realtime measurement data from the one or more sensors of the first patient, wherein the identified rule is applied to generate an alert indicator for the first patient. At least one rule from a population rules engine is identified to apply to the first patient using the real-time or near real-time measurement data from the one or more sensors of the first patient and measurement data from a patient population, wherein the identified rule is applied to generate a health assessment for the first patient. A user interface is then generated for display on a device of a care provider, wherein the user interface displays one or more of the real-time or near-real time measurement data, the status report, the alert indicator, and the health assessment of the first patient.

[0011] In some embodiments, methods for increasing caregiver productivity in senior care are disclosed. Such methods comprise automatically monitoring activities and other information about patients and caregivers through the use of fixed sensors, wearables, communication devices, and other hardware and software. Such methods also comprise analyzing the gathered data to identify areas of efficiency and effectiveness improvement, and monitoring compliance with policies, procedures, instructions, and regulations. In addition, real-time or near real-time feedback, insights and instructions are provided to caregivers and managers of care providers to (1) enhance caregiver productivity, effectiveness, and efficiency, (2) improve caregiver compliance with policies, procedures,instructions and regulations, and (3) prioritize caregiver actions and interventions according to the particular policies, procedures, instructions and regulations applicable to the caregiver and the patient.

[0012] Various objects, features, aspects, and advantages of the inventive subject matter will become more apparent from the following specification, along with the accompanying drawings in which like numerals represent like components.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. 1 illustrates an overview diagram of a cloud-based remote health care alert system in accordance with some embodiments.

[0014] FIGs. 2 and 2A illustrate several exemplary graphical user interfaces (GUIs) for caregivers in accordance with an example.

[0015] FIG. 3 illustrates a method of generating one or more care alerts for a patient according to some embodiments.

[0016] FIG.4 illustrates a method of assigning a caregiver to respond to an urgent care alert of a patient according to some embodiments.

[0017] FIG. 5 illustrates a graphical user interface (GUI) of a caregiver overview dashboard screen according to some embodiments.

[0018] FIG. 6 illustrates a GUI of a first dashboard status for an individual patient according to some embodiments.

[0019] FIG. 7 illustrates a GUI of a second dashboard status for an individual patient according to some embodiments.

[0020] FIG. 8 illustrates a GUI of a third dashboard status for an individual patient according to some embodiments.

[0021] FIG. 9 illustrates a graphical user interface (GUI) of an initial daily summaries screen according to some embodiments.

[0022] FIG. 10 illustrates a GUI of a first transition screen showing a first alert according to some embodiments.

[0023] FIG. 11 illustrates a GUI of a second transition screen showing a second alert according to some embodiments.

[0024] FIG. 12 illustrates a GUI of a third transition screen showing a third alert according to some embodiments.

[0025] FIG. 13 illustrates a GUI of a fourth transition screen showing a table view for Wednesday, 15 February 2023 according to some embodiments.

[0026] FIG. 14 illustrates a GUI of an initial analytics screen showing analytics in a graphical form with colors according to some embodiments.

[0027] FIG. 15 illustrates a GUI of a first transition screen showing analytics in a graphical form with colors according to some embodiments.

[0028] FIG. 16 illustrates a GUI of a second transition screen showing analytics in a graphical form with colors and a filter selection by nighttime bathroom visits daily count according to some embodiments.

[0029] FIG. 17 illustrates a GUI of a third transition screen showing analytics in a graphical form with colors and a filter selection by nighttime bathroom visits daily count according to some embodiments.

[0030] FIG. 18 illustrates a GUI of a fourth transition screen showing analytics in a graphical form with colors and a filter selection to selected properties according to some embodiments.

[0031] FIG. 19 illustrates a GUI of a fifth transition screen showing analytics in a graphical form with colors and a filter selection to selected properties with a cursor highlighting a nighttime bathroom visits daily count for one night according to some embodiments.

[0032] FIG. 20 illustrates a GUI of a sixth transition screen showing analytics in a graphical form with colors and a filter selection to only properties with alerts according to some embodiments.

[0033] FIG. 21 illustrates a block diagram of a computer system that can be used for implementing one or more aspects of the various embodiments.

[0034] While the invention is described with reference to the above drawings, the drawings are intended to be illustrative, and other embodiments are consistent with the spirit, and within the scope, of the invention.DETAILED DESCRIPTION

[0035] The various embodiments now will be described more fully hereinafter with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific examples of practicing the embodiments. This specification may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this specification will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Among other things, this specification may be embodied as methods or systems. Accordingly, any of the various embodiments herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. The following specification is, therefore, not to be taken in a limiting sense.

[0036] To provide a more thorough understanding of the present invention, the following description sets forth specific details, such as specific configurations, parameters, colors and / or patterns employed in exemplary user interfaces where the drawings are depicted in black and white, specific examples, and the like. It should be recognized, however, that such description is not intended as a limitation on the scope of the present invention but is intended to provide a better description of the exemplary embodiments.

[0037] According to various embodiments, the present disclosure may be directed to systems and methods for generating one or more care alerts for one or more patients.

[0038] One should appreciate that the disclosed techniques provide many advantageous technical effects including an interactive user interface for generating a computer-implemented interactive graphical user interface for generating one or more care alerts for one or more patients.

[0039] One should appreciate that the disclosed techniques provide many advantageous technical effects including interactive computer interface methods for visually reviewing, identifying and responding to care alerts from senior, disabled and other patients that require remote monitoring and / or medical assistance. The disclosed techniques have been designed to support reviewing, identifying, monitoring and routing care alerts on a scale and speed that cannot be achieved using manual human effort.

[0040] It should also be appreciated that the following specification is not intended as an extensive overview, and as such, concepts may be simplified in the interests of clarity and brevity.

[0041] Examples of the disclosed system provide a user-friendly interface not only for caregivers, but also for family members and patients or residents themselves, where all can actively engage in care monitoring and decision-making. Examples of the disclosed systems provide real-time updates on health and behavior, enabling families to receive notifications about their resident loved one and / or check care progress remotely. In some aspects of the disclosed platform, a user interface can be configured for both caregivers and family members, wherein the interface provides monitoring of real-time health metrics and behavioral data of a resident through one or more connected sensors. Examples of such engagement platforms can include interfaces such as dashboards or mobile apps that provide updates about a resident or patient, enabling remote engagement and monitoring of health, behavior, or living conditions by authorized family members.

[0042] Examples of the disclosed system also can leverage artificial intelligence, including machine learning algorithms and predictive analytics to analyze historical patient data and behaviors, and forecast potential health events or risks such as falls, infections, or changes in behavior. In some aspects, the disclosed system is designed to provide alerts to caregivers and family members early when problems first arise, enabling timely interventions before conditions or problems worsen or become critical. Examples of the disclosed system are configured to analyze historical and real-time data from one or more sensors using machine learning algorithms, wherein the system predicts potential health risks such as falls or dehydration, and generates alerts based on deviations from established behavioral or physiological baselines for a monitored individual. Such alerts could predict potential health risks beyond simply noting biometric or other data obtained from using traditional sensor-based methods.

[0043] In addition to monitoring physical health of the resident, examples of the disclosed system can identify and track behavioral changes, such as unusual and / or extended periods of inactivity, social isolation, or irregular sleep patterns, all of which may indicate emotional or psychological distress. In some embodiments, such tracked changes can trigger customized alerts for caregivers and family members, thus facilitating early intervention with the resident beforeproblems can arise and / or worsen. Thus, some examples of the disclosed system monitor behavioral and emotional changes in a patient or resident. These examples systems use one or more sensors to track physical activity, sleep patterns, or environmental interactions, wherein deviations from the patient or resident’s normal behavioral patterns indicate potential emotional or psychological distress and can trigger automated alerts to caregivers and / or family members to facilitate early intervention.

[0044] In some examples, the disclosed system enables the customization or personalization of care plans for each of one or more patients or residents, based on ongoing data of the patient or resident, such as the patient or resident’s unique needs, preferences or medical conditions of the resident or patient. Over time, examples of the disclosed system dynamically adjust the care plan for each of one or more patients or residents based on ongoing health data of the one or more patients or residents, thus optimizing the delivery of care for each individual resident or patient. Thus, examples of the disclosed system are configured to generate and dynamically update personalized care plans for each of one or more individual residents or patients, wherein the personalized care plans are adjusted in real time based on data from one or more sensors or user inputs. Data from the one or more sensors and the one or more user inputs can be analyzed to help ensure that individualized and responsive care tailored to the specific health conditions and preferences of the resident or patient is delivered. In some examples, data from the one or more sensors and the one or more user inputs can be analyzed by one or more machine learning models or algorithms, to further optimize the individualized and responsive care delivered to the resident or patient.

[0045] Examples of the disclosed system further improve operational efficiency and financial performance of care facilities using real-time data analysis tools that optimize caregiver task prioritization, reduce hospital admissions, and provide operational insights to help care facilities reduce costsand enhance service quality. For example, the disclosed system can improve the operational efficiency of senior living communities by automating routine care tasks, enabling more effective prioritization of caregiver activities, and reducing hospital admissions. In some examples, real-time analytics of the disclosed system help care facility operators optimize staffing, streamline operations, and demonstrate improved health outcomes, thereby enhancing revenue potential of the care facility implementing aspects of the disclosed system.

[0046] FIG. 1 illustrates an overview diagram of a cloud-based remote health care alert system 100 in accordance with some embodiments. System 100 may comprise, in some embodiments, a cloud-based platform for collecting and analyzing data related to the health, well-being, and safety of patients, including senior citizens and disabled people. In some examples, patient care alerts, patient status information and patient health insights may be delivered to carers and care providers from a system platform 120 via cloud / web 118 using a graphical user interface (GUI) delivered via a mobile application to devices 110 and 114, which may comprise a mobile phone, tablet, or similar device; and / or desktop application via a desktop or laptop computer 112. Alternatively, patient care alerts, patient status information, and patient health insights may be delivered to carers and care providers through text messages (e.g., SMS (Short Message Service), email, XML (extensible Markup Language), mobile phone app notifications, or other methods.

[0047] As discussed herein, carers and care providers will be able to utilize the GUI to see and explore relationships between a patient’s sleep, bathroom visits, blood glucose levels, medication use, and other health and activity data, wherein such data may be stored in patient database 125. Database 125 may include a broad and comprehensive collection of measurements and data enabling algorithms relying on combinations of dissimilar data (such as sleep quality, bathroom visits, and medication compliance) to be applied and utilized on an individual patient basis as well as for longitudinal (time-based) andanalysis across one or more populations. Summary reports containing measurement trends and data for individual patients may also be generated via reporting module 126. In some embodiments, caregiver database 123 may include information on caregivers, including but not limited to: Caregiver Name, Caregiver Skills, Assigned Patients (e.g., VIPs or Seniors), Rate / hr, Current Status (e.g., On / Off Shift, Current Task, Time to Current Task Completion, Time to Off Shift / On Shift, Current Location, Current Available Supplies).

[0048] In some embodiments, third party clients may also be able to utilize the patient data from patient database 125 within system platform 120 where appropriate and permissible via application programming interfaces (APIs), including Patient (e.g., VIP (Vulnerable Independent Person) API 124. In some embodiments, the APIs may be Open API 3.0 (or higher) compliant. Third party clients may include alarm response center systems 131 (e.g., exemplary third party client alarm response systems 131 may include those for assisted living facilities such as Legrand / Jontek), electronic health records systems 133 (e.g., exemplary third party client EHR systems 133 may include systems produced by Patients Know Best (PKB)) , and care management systems 135 (e.g., exemplary client carer applications 135 may include software systems produced by The Access Group).

[0049] Individual rules engine 150 will, in some embodiments, monitor database 125 at regular intervals or at one or more specified times during the day. The intervals for monitoring may be stored in a dedicated memory, Patient (e.g., VIP) Settings 127 accessible by individual rules engine 150. The monitoring intervals may vary according to each individual patient and by the particular data sources that are configured for the individual patient’s circumstances. Depending on the monitoring interval, one or more insights may be generated and stored in patient (VIP) Insights database 128. Patient Insights database 128 may include notifications, alerts and warnings. Patient Insights database 128 may also include anomalies, rule breaches (e.g., of rules inindividual rules engine 150 or population rules engine 152) and suggested investigations. Such insights may also be generated using results generated by Machine Learning Engine 129 and trained on data from patient database 125 (or data from external databases such those included in EHR system 133) in accordance with machine learning implementations created as described herein.

[0050] In some embodiments, some insights generated may comprise simple notifications, e.g., “Low Hydration.” Low hydration may be detected via a sensor in the patient’s drinking water bottle, cup, or water dispenser, indicating that a lower-than-average amount of water was consumed or dispensed, for example, and may trigger a notification to the patient to drink more water. In some embodiments, other insights generated may utilize more complex logic, which may note an anomaly, rule breaches, or suggested investigations. For example, one insight notification may include the following that includes an anomaly or rule breach: “The patient (VIP) is out of bed at night, has visited the bathroom, but is not back in bed more than 30 minutes since their bathroom visit.” Such insights may generate a suggested investigation, e.g., an urgent alert notification to a caregiver to check on the patient, for example. Thus, an insight, including notifications, alerts, and warnings, may comprise a piece of information (e.g., VIP is out of bed at night), a value that has fallen outside of a permitted range (e.g., sleep score is too low), a combination of pieces of information (e.g., a combination of a high sleeping heart rate, high nighttime bathroom use, and poor sleep quality signifies a need to check for infection), a rate of change in a value (e.g., hydration is falling each day by more than 1%), or an instruction to do something (e.g., change continence pad).

[0051] Population rules engine 152 will apply general rules or algorithms across one or more patient populations for which measurement data is gathered and stored in patient database 125. Such rules may be derived from published clinical and academic research. New algorithms or rules may be added as new research is published. One example of such an algorithm is based on researchpublished by Surrey University in the United Kingdom which detects increased likelihood of a urinary tract infection (UTI) based on trends in sleep quality and bathroom visits. Other rules may be generated based on longitudinal trends and changes in behavior over time, which may also be derived using machine learning techniques applied over health, sleep, activity, safety, medication, nutrition and other data obtained from one or more patient populations stored in patient database 125. In some embodiments, patient database 125 and caregiver database 123 may be structured for individual, longitudinal (time-based), and population-wide analysis.

[0052] In some embodiments, sensors and devices located on a patient or within a patient’s sleeping room or residence may be connected through cloud 118 to transmit patient data to patient database 125 within system platform 120 where appropriate and permissible via application programming interfaces (APIs), such as data API 122. In some embodiments, data API 122 will enable multiple integration channels to bring patient data to platform 120. In some examples, the API 122 may be Open API 3.0 compliant, and support third party integration services, enabling new devices and data sources to be readily added. Patient database 125 may in some embodiments include biographical, biometric, or health-related data of a patient, including but not limited to: Name, Age, Gender; Address / Facility / Room; Health Conditions; Medications, List of Needed Caregiver Tasks and Timing Frequency; Patient Personal Preferences (e.g., don’t enter room except in emergency); Patient Specific Needs (e.g., starting new medication which may make patient unsteady at night).

[0053] In some embodiments, sensors and devices may include, but are not limited to, devices that are already proven to be effective, safe, and reliable at scale, and may be supported by secure, certified, and high-performance platforms, and proprietary, open and / or published APIs. Such sensors and devices may include, in some embodiments, connected gas, smoke, carbon monoxide, and heat alarms 147 (e.g., connected via a third party API such asFireAngel); connected sleep mats, scales, blood pressure monitors, thermometers, heart rate monitors, and pulse oximeters 145 (e.g., connected via a third party API such as Withings); connected activity, presence, power consumption, and other sensors 141 (e.g., connected via a third party API such as Samsung); and connected medication dispensers 143 (e.g., connected via a third party API such as Hero).

[0054] In some embodiments, platform 120 may be constructed using Ruby on Rails server-side web application framework, although other similar web application frameworks may be used. Patient database 125 may be built using PostgreSQL relational database management system in some embodiments, and may take advantage of a flat JSONB (Java Script Object Notation Binary) data type or data structure for storing and manipulating data. In some embodiments, a front end of platform 120 may be constructed using JavaScript and HTML (Hypertext Markup Language) programming languages, and Haml (HTML Abstraction Markup Language) templating engine for HTML. Hotwire (which stands for HTML over the wire) provides client-side interactivity in some embodiments, using Turbo to manage HTML requests to the server and direct responses.

[0055] In some embodiments, server-side memory caching may be performed by three Memcached instances and one Redis (Remote Dictionary Server) data structure server instance for background jobs caching. Memcached is a free and open source, high-performance, distributed memory object caching system used in dynamic web applications.

[0056] FIG. 2 and FIG. 2A illustrate several exemplary graphical user interfaces (GUIs) for caregivers in accordance with an example. Desktop application 210 (in FIG. 2) running on desktop computer 112, and mobile applications 220, and 230 (in FIG. 2A) running on mobile devices (e.g., tablets and / or smart phones) 110 and / or 114 respectively (where computing devices 110,112 and 114 are running on or more of, e.g., iOS, Windows and / or Android operating systems) may be developed in some embodiments using React Native open-source UI (user interface) software framework. Mobile push notifications and email notifications may be handled in some embodiments using OneSignal and Postmark or similar services.

[0057] In some embodiments, system 100 may include real-time unification of data from multiple dissimilar sources, where each source presents unique requirements in terms of API configuration, security profile, content negotiation, data format and schema, minimum latency, and acceptable return codes. Data cycles may be triggered by user events. In some embodiments, a constantly- available, ultra-low latency webhook or HTTP-POST endpoint of sending data with an at-least-once delivery feeds into a queue-triggered cloud-based workflow. The workflow will retrieve data from the source API, identify the user and reformat it to a schema for patient database 125, and then relay the reformatted data to a secure ingestion endpoint for patient database 125. In some exemplary use cases of system 100, data elements may be personal and in many cases, classified as sensitive and involving individual biometric readings, etc. Sensitive health-related data may require high-specification transport security and encryption at rest, In some embodiments, each leg of the data cycle may utilize individual OAuth / OIDC-based security authentication, with a complex requirement to persist authorization for each API in the form of a linked set of securely-stored OAuth refresh tokens, each of which is itself renewed with each data cycle.

[0058] In some embodiments, low public endpoint latency (e.g., up to 2 second round trip), low operational end-to-end latency (e.g., approximately 800-1600 ms from data ingestion at e.g., sensors 141, 143, 145, and 147, to receipt of the POST request at the web server of platform 120, and low processing cost is desired. In particular, low processing cost may be important for non-statechanging events such as repeat motion sensor signals which may occur withgreat frequency (e.g., approximately 60 - 90 signals per minute, per source), and which should be identified and discarded with minimum cost and minimum resource consumption.

[0059] FIG. 3 illustrates a method 300 of generating one or more care alerts for a patient for the purpose of monitoring and improving senior care, according to some embodiments. In operation 320, real-time or near real-time measurement data is received from one or more sensors located in a living environment of a patient. Sensors and devices (such as those described with respect to connected devices 141, 143, 145, and 147 of FIG. 1) may be strategically placed around a senior’s home and elsewhere to gather information. In operation 340, real-time or near real-time measurement data from the one or more sensors is used to generate a status report of the patient. Such a status report may include data as shown in exemplary GUIs 210, 220, and 230 of FIG.2. For example, data related to sleep duration, time to fall asleep, sleeping heart rate, breathing rate, bed time, wake-up time, and time to get out of bed, may be measured via a connected sleep mat or operation of a connected CPAP (continuous positive airway pressure) machine. Door sensors or motion sensors may measure the number and duration of nighttime bathroom visits, or time away from home, for example.

[0060] In operation 360, in some embodiments, at least one rule pertaining to the patient from an individual rules engine (e.g., individual rules engine 150) is identified using the real-time or near real-time measurement data to generate an urgent, caution or stable alert. In some examples, an alert may comprise a piece of information or data, a value that has fallen outside of a permitted range (e.g., measurement out of bounds alert), a combination of two or more pieces of information, a rate of change in a value, or an instruction to do something. For example, an alert may comprise one or more of: an in bed alert, an out of bed alert, a door open alert, an appliance on alert, a possible fall alert, a continence alert, a missed medication alert, a late bedtime alert, a late home alert, a patientout of bounds alert, an inactivity alert, a measurement out of bounds alert, or a configurable measurement alert. In some embodiments, a patient out of bounds alert may occur if a patient is located in an area that is outside their normal location. In some embodiments, an inactivity alert may be generated when a combination of circumstances occurs which indicates that a VIP may need assistance, e.g., it is night time and the patient is at home, has gotten out of bed, has not gotten back into bed, and has not done anything for 30 minutes. In some embodiments, a measurement out of bounds alert is generated when a measurement is too high, too low, or changing too quickly. For example, an alert could be generated for measurements such as skin temperature, body temperature, heart rate, out of bed count, bathroom visit count, wakeup count, blood pressure, sleep score, step count, breathing rate, pain score, or other similar measurements. In some embodiments, an alert is generated based on a user (e.g., care provider) configurable combination of measured data points (e.g., an elevated sleeping heart rate plus an elevated number of night time bathroom visits plus reduced sleep quality), or any similar alert that may indicate investigation by the care provider is needed.

[0061] Other examples of alerts include the following Safety and Mobility Alerts which can be detected via one or more smart devices such as sleep mats, motion sensors, door sensors, toilet sensors, and safety floor tracking mats that do not pose a trip hazard.

[0062] - Out of Bed at Night Alert: Patient gets out of bed during the night and doesn’t return within a set time frame.

[0063] - Possible Fall Alert: Detected unusual movement patterns or long periods of inactivity that suggest a possible fall.

[0064] - Increased Fall Risk Alert: Multiple indicators such as reduced activity, slower movement, or instability detected through gait analysis.

[0065] - No Movement Detected for a Prolonged Period: Inactivity detected beyond a safe threshold (e.g., no motion detected in 6 hours during the day).

[0066] - Frequent Bathroom Visits Alert: The patient has an unusually high number of bathroom visits during the night, which could indicate urinary tract infections (UTIs) or other issues.

[0067] - Wandering Alert: Patient leaves a designated safe zone or the residence, which is especially important for individuals with dementia.

[0068] - Assistive Device Not Used: The patient is detected walking without using their prescribed walking aid (e.g., walker, cane), increasing fall risk. Such detection can be performed using a motion sensor with an accelerometer, which can be attached to the patient and / or the prescribed walking aid.

[0069] Examples of Medication and Health Monitoring Alerts include the following which in some embodiments can be detected through smart pillboxes or similar devices, for example:

[0070] - Missed Medication Alert: Patient does not take medication at the scheduled time (tracked through smart pillboxes or similar devices).

[0071] - Late Medication Alert: Medication is taken, but later than the prescribed window.

[0072] - Medication Taken Twice Alert: Patient takes the same medication more than once in a short time, indicating possible overdose.

[0073] - New Symptom Reported Alert: The patient reports a new symptom via a self-assessment tool available on some embodiments of platform 120 (e.g., pain, dizziness, or nausea). For example, a self-assessment tool could include a GUI available on a tablet, smart phone, smart watch, or laptopcomputer of the patient or resident where the patient could press a button to indicate a high level or sudden onset of pain, dizziness or nausea.

[0074] - Low Adherence to Medication Regimen Alert: Over time, if adherence to medication schedules drops below a certain threshold (for example, if a smart pillbox reports a threshold number of missed medications, an alert for the patient may be triggered).

[0075] - Non-Adherence to Treatment Plan Alert: If the patient is not following a prescribed treatment plan (e.g., not using a prescribed device like a CPAP machine).

[0076] - Abnormal Heart Rate Detected Alert: Heart rate readings from one or more wearable devices fall outside a preset range.

[0077] - Abnormal Blood Pressure Detected Alert: Blood pressure readings indicate hypertension or hypotension.

[0078] - High Pain Score Reported Alert: The patient reports high levels of pain using the Amba platform’s self-assessment tool as described above.

[0079] Examples of Sleep and Respiratory Monitoring Alerts used in some embodiments of the disclosed platform include the following:

[0080] - Poor Sleep Quality Alert: Patient’s sleep data (e.g., restless movements, frequent wakeups) indicates poor sleep quality and may be tracked through one or more detection devices such as motion sensors, and smart devices such as a sleep mat.

[0081] - Sleep Apnea or Breathing Irregularities Detected: Detected through sleep monitors or CPAP machines.

[0082] - Abnormal Breathing Pattern Alert: Respiratory rate outside the expected range during sleep or while at rest.

[0083] - Excessive Daytime Sleepiness Alert: Data from wearable devices or motion sensors shows the patient is taking naps or is less active during the day.

[0084] - Snoring or Increased Noise Detection Alert: Detected increase in snoring or noisy breathing can be detected via noise detectors, indicating potential respiratory problems.

[0085] - Low Oxygen Saturation Alert: Pulse oximeter detects oxygen levels below a set threshold, especially during sleep.

[0086] Examples of Environmental Alerts used in embodiments of the disclosed platform include the following:

[0087] - High Temperature Alert: Smart thermostats or thermometers can be used for alerting when room temperature is detected to be too high, which could be dangerous for elderly patients.

[0088] - Low Temperature Alert: Smart thermostats or thermometers can be used for alerting when room temperature is too low, indicating a risk of hypothermia or environmental discomfort.

[0089] - High Humidity Alert: Humidity levels in the room environment are detected to be too high, which can increase respiratory issues.

[0090] - Smoke / Fire / CCh Detection Alert: Smart smoke, fire, or carbon monoxide detectors report a dangerous event.

[0091] - Lights Left On at Night Alert: Patient has left lights on during the night, potentially indicating confusion or wandering.

[0092] Examples of Nutrition and Hydration Alerts used in embodiments of the disclosed platform include the following:

[0093] - Low Fluid Intake Alert: The patient is not drinking enough water, based on smart hydration bottles or fluid intake trackers.

[0094] - Missed Meal Alert: Patient has missed a meal, which could be detected through connected kitchen sensors or smart appliances.

[0095] - Weight Loss Detected Alert: Significant, unexplained weight loss detected by a connected smart scale.

[0096] - Low Appetite Alert: Based on tracked food intake, the patient’s appetite has significantly decreased.

[0097] Examples of Cognitive and Behavioral Monitoring Alerts used in embodiments of the disclosed platform can include the following, which may involve motion sensors, connected kitchen sensors, smart appliances, and tracking such data from such routine daily activities:

[0098] - Unusual Behavior Pattern Alert: Detected changes in regular activity patterns that might suggest cognitive decline or confusion (e.g., wandering, not following usual routines).

[0099] - Increased Confusion Alert: Multiple indicators such as wandering or failure to complete basic tasks (e.g., getting dressed, making meals) suggest cognitive deterioration.

[0100] - Memory Lapses Detected: Detected through missed or repeated activities that indicate memory lapses (e.g., forgetting to turn off the stove, leaving the fridge open).

[0101] - Unusual Sleep / Wake Cycles Alert: Significant deviations from regular sleep / wake patterns, suggesting cognitive or mental health issues.

[0102] Examples of Social Engagement and Communication Alerts used in embodiments of the disclosed platform can include the following:

[0103] - Low Interaction / Engagement Alert: The patient has shown little social interaction or engagement over a set period, possibly indicating isolation or depression and may be tracked through motion sensors or wearable devices.

[0104] - Missed Scheduled Social Activity Alert: The patient missed a scheduled social or recreational activity, which could be an early sign of social withdrawal or health decline and may be tracked through an app -based check, for example.

[0105] - Failed Check-In Alert: Patient has not completed a scheduled checkin, either through a wellness call or app-based check.

[0106] In some examples, Hygiene and Personal Care Alerts used in embodiments of the disclosed platform can include the following:

[0107] - Missed Personal Care Routine Alert: Bathroom sensors or door sensors can be used indicate that a patient has skipped a personal care routine (e.g., showering, dressing).

[0108] - Unusual Bathroom Usage Alert: Significant changes in bathroom habits detected via bathroom sensors or toilet sensors can detect events or patterns such as increased or decreased usage, which may suggest digestive or urinary issues.

[0109] - Continence Pad Change Needed Alert: Detected using sensors or smart continence products that alert when a change is needed.

[0110] In some embodiments of the disclosed platform, examples of Movement and Activity-Based Alerts can include the following:

[0111] - Low Activity Level Alert: Wearable devices such as activity or fitness trackers can be used to detect low physical activity levels that fall below a set threshold, potentially indicating lethargy or health issues.

[0112] - Over-Activity Alert: Activity trackers and other wearables can be used, for example to detect unusually high activity that could lead to fatigue or injury (e.g., moving too much after surgery or injury).

[0113] - Sedentary Period Alert: Activity trackers and other wearables can also be used to detect extended periods of inactivity that might increase health risks, such as blood clots, obesity, or muscular atrophy.

[0114] - Abnormal Gait or Walking Pattern Alert: Detected irregular walking patterns can indicate weakness, instability, or the onset of health issues like arthritis. Such irregular walking patterns can be detected by an accelerometer worn by the patient or resident on a lightweight wristband.

[0115] Examples of the disclosed platform can also include General Health Deterioration Alerts that can be based on data from one or more devices that can be tracked simultaneously and / or over a period of time”

[0116] - Overall Health Decline Alert: Based on multiple data sources (e.g., sleep, activity, eating, and health reports), the platform detects a gradual decline in overall health.

[0117] - Sudden Health Deterioration Alert: A combination of factors such as irregular heart rate, sudden weight loss, or failure to perform daily routines, indicating a serious health issue.

[0118] In some embodiments, alert types can be explicitly created on platform 120 by a person, or can be created using artificial intelligence (Al) and / or machine learning (ML) technological capabilities in platform 120 and made available to users. In some embodiments, system 100 can be provided withsymptoms and indications for each VIP / patient which in combination or isolation may indicate possible problems or risks. Over time, system 100 may also identify related problems or issues which actually occur to VIPs and derive possible relationships to symptoms and indications which may happen hours, days, or months earlier. Such information may be used to create alerts for carers and other care providers enabling them to investigate further immediately or provide insights to investigate and / or consider later.

[0119] The information and related alerts may be presented in real time on the desktop, mobile app, and tablet user interfaces as described above using a push notification, an icon changing color or shape on the patient summary screen, a sound emitted on the GUI, the order of VIPs changing on the GUI according to the changing urgency of attention (both up and down), and / or as a summary report of all alerts, or an exported report of alerts. On other interfaces, information and related alerts may be presented, e.g., as a push notification on a mobile device, robotic phone call, SMS, via an existing alarm systems such as a nurse call system, via a speaker or smart speaker, or via API into an alarm receiving center (ARC), or via email or other communication as follows:Wellbeing Alert: Check for infection — Jackie’s night time bathroom visits are increasing, her sleep quality is decreasing, and her sleeping heart rate is higher than usual.

[0120] There are several different ways in which machine learning may be applied to create insights and alerts. For example, in some embodiments, a time series analysis may be performed using a type of recurrent neural network using Long Short Term Memory (LSTM) cells for sleep pattern detection, to monitor and assess sleep quality of a person over time. LSTM networks are well-suited for time series data such as sleep patterns. By comparing sequential data of seniors’ nightly rest such as data on sleep cycles detection, snoring, breathing disturbances, and heart rate obtained from a sleep tracking mat that is used in aperson’s bed or a wearable device such as an accelerometer or actigraph, for example, deviations from typical sleep patterns may be identified using LSTM. In some embodiments, if the LSTM networks trained by and implemented in system 100 detects significant irregularities, such as prolonged periods of restlessness, the system generates an “Alert” or “Insight” indicating potential sleep disturbances or health issues, and transmits these alerts or insights to the user interfaces of the care providers.

[0121] In other embodiments, anomaly detection using one-class support vector machines (SVM) may monitor seniors’ activities. SVMs, and one-class SVMs in particular, may be used to detect unusual activities or inactivity, such as extended periods of not getting out of bed, or unusually slow movements or reduced gait speed that could indicate a potential fall or other health-related issue. In some embodiments, the one-class SVM algorithm is trained primarily on data comprising “normal data” generated from normal everyday activities and movements of individual people such as seniors, on an individual basis as well as over a group or population of seniors. Detected anomalies may generate notifications to care providers in system 100 in the form of an “Alert” for a potentially harmful situation requiring immediate action (like a potential fall), or an “Insight”, for less urgent but still unusual patterns of activity or inactivity that should be flagged to care providers for further investigation.

[0122] In some other embodiments, random forest classifiers are used to predict healthcare -related behavior of seniors, such as medication adherence. For example, random forest classification may be used to predict if a senior may miss their medication based on past behaviors, environmental factors, or health conditions. In such embodiments, random forest classifiers utilize multiple decision trees during training and output the class that is selected by the most trees for classification. By inputting data on when and how often seniors take their medications, the random forest classifier can predict with a certain probability if a particular senior is likely to miss a dose. An “Alert” or “Insight”can then be generated in anticipation of a missed dose, allowing caregivers to intervene proactively. In all cases, the models may be retrained periodically or continuously with fresh patient data to ensure accuracy and relevance, especially as seniors’ habits and health conditions change over time.

[0123] In some embodiments, instances of alerts may have settings or values that can be set for: an entire patient population; for a group of people in one care facility, department, floor or building; for a group of people with similar characteristics, behaviors, conditions, and / or history, and for an individual. As described below, alerts may be set manually, automatically, or by using Al and / or ML as previously discussed. In addition, settings for an individual or a group may, in some embodiments, be continuously, periodically, and / or automatically changed by or via the platform based on the changing behavior or habits of the individual; information provided about the individual’s condition, preferences or needs; or information about other people derived from within platform 120 or externally.

[0124] In some embodiments, new alert types may be created manually, semi- automatically, or automatically by platform 120. In one example, a manual alert may be created when someone (e.g., a platform user) tells the platform what the alert is, e.g., an alert is created if a patient is detected to be out of bed at night for longer than a specified amount of time, e.g., 30 minutes.

[0125] In operation 380, at least one rule is identified to apply to the patient from a population rules engine using the patient’s real time measurement data and measurement data from a patient population to generate a health assessment (or, in some examples, an alert) for one or more patients.

[0126] In operation 390, a user interface is generated in some embodiments for display of a care provider device that displays one or more of the patient’s measurement data, the status report, the alert indicator, or the patient’s health assessment.

[0127] In another example, a semi-automatic alert may be created when a platform user, e.g., a carer or care provider, tells the platform 120, e.g., “People over 80 years old who get out of bed more than three times a night are four times more likely to suffer a fall if they do not use their walking aid.” So, the system creates a new alert, e.g., “If a patient gets out of bed at night and does not move their walking aid within X seconds, alert a care provider.” In this example, the settings may include the age of patient, number of times patient gets out of the bed, and the amount of time before an alert is created.

[0128] In some embodiments, an automatic alert is where platform 120 creates a new alert type based on data it has analyzed, e.g., using machine learning engine 129. The analyzed data may have been gathered by sensors connected to a patient or in a patient’s home, or the analyzed data may be from other sources. For example, platform 120, via machine learning engine 129 may identify a possible relationship between a patient having a urinary tract infection (UTI) and earlier increasing nighttime bathroom visits and sleeping heart rate. So, platform 120 creates a new alert type which alerts to a possible UTI when increasing bathroom visits and sleeping heart rate are noticed.

[0129] FIG. 4 illustrates a method 400 of assigning a caregiver to respond to an urgent care alert of a patient according to some embodiments. Such methods may enable system 100 to help monitor and improve senior care. Machine learning algorithms as described above may also be used in some examples to provide insights and recommendations to caregivers. Caregiver productivity may also be increased as caregivers can provide more efficient care to seniors. For example, information about the needs and preferences of patients may be stored in database 125. Similarly, information about the skills and qualifications of caregivers that are currently working on shift may also be stored in database 125 or another database accessible to platform 120. In some examples, current information about an on-shift caregiver may also be stored. For example, the caregiver’s current location and information about how lengthy and importantthe task that they are currently working on may be provided. Information about the current needs of other patients assigned to the caregiver on shift, and the likely needs of other patients over the coming hours may also be stored in a database accessible to platform 120.

[0130] In operation 420, in some examples, upon receiving an urgent alert indicator for at least one rule for the patient, an urgent care request is generated for the patient. The urgent care request may comprise a caregiver qualification, a location, a time duration, and a supply list. As described above, system 100 may automatically monitor activities and other information about patients through the use of fixed sensors, wearable sensors, communication devices, and other hardware and software. Caregiver activities and location may also be monitored and / or tracked in a comparable manner as discussed above. In operation 440, one or more caregiver profiles are analyzed. In some embodiments, a caregiver profile may comprise a caregiver qualification, a current location, a time remaining on current shift, a supply inventory, and an on-call status.

[0131] In operation 460, a caregiver profile of at least one care provider having a caregiver qualification, a current location, a time remaining on current shift, and a supply inventory that generates a match (or at least a closest match from the caregivers currently working) with the urgent care request for the patient is identified. In operation 480, an instruction alert is transmitted to a user device of the matched or identified care provider, instructing the identified care provider to fulfill the urgent care request of the patient, and attend to the patient’s care needs. In some examples, the system may wait to see if the task is accepted by the closest matched care provider before notifying one or more of the other care providers of the urgent care request. After the task is accepted, platform 120 may gather information about whether and when the instructed care interventions were performed to address the urgent care request, and by whom.

[0132] For example, in one scenario, a medication sensor (Sensor 1) located in a patient residence may detect that medication has been missed and a continence sensor (Sensor 2) may detect that a continence pad needs changing soon. An urgent care alert may be generated for the patient according to a rule as discussed above. Platform 120 will be able to determine, in this example, what care providers are currently on duty, what qualifications each care provider have, what permissions and knowledge they possess, what supplies they have with them, whether they are likely to be needed elsewhere (or are going off duty soon), and how much they cost (e.g., their hourly rate). Using this information, platform 120 selects one or more care providers and requests or instructs them to attend to the patient’s needs as identified above. In one embodiment, the care provider may accept or reject the request.

[0133] In some embodiments, platform 120 may be used to prioritize and schedule care provider actions. For example, in providing care to seniors in a care facility at night, personal patient preferences, policies, regulatory requirements, and specific needs may come into play. For example, the patient may have a personal preference that no one enters their room at night except in an emergency. Care provider facility policy may, however, require that a wellness check be conducted on each resident every 3 hours. Regulatory requirements may specify that for certain medical conditions or level of need (e.g., hospice care), all government-subsidized care provisions must include an hourly (or other regular interval) nighttime well-being check. In addition, a specific patient need may be identified (e.g., a resident patient has started a medication which makes them unsteady on their feet at night, and therefore needs an hourly nighttime well-being check). In addition, there may also be a machine learning / AI component to determining this specific need which may be implemented as described above. For example, men over age 80 who take a particular medication and have high blood pressure may be known to experience dizziness when starting this particular medication. System 100 may then trackthis data across the patient population. In such cases, machine learning components implemented as described above in embodiments of the present invention may ascertain that this is a potential concern by tracking such data, e.g., the age of people of take this medication, have hypertension, and experience dizziness / falls.

[0134] In one example, platform 120 evaluates the needs, preferences and policies described above with real-time information collected by the patient and care provider’s sensors and devices in order to prioritize and / or schedule the actions of the care provider, e.g., Caregiver 1 should go to room 345 next.

[0135] Platform 120 may also help increase care provider productivity in providing senior care, particularly when analyzing the gathered data for efficiency and effectiveness improvement, and monitoring compliance with policies, procedures, rules and regulations.

[0136] Platform 120 may also provide real-time feedback, insights, and instructions to care providers and care provider facility coordinators to enhance their productivity, effectiveness and efficiency; and also improve their compliance with policies, procedures, instructions and regulations.

[0137] In addition, platform 120 may help prioritize care provider actions and interventions according to the particular policies, procedures, instructions, and regulations under which they are working.

[0138] In some embodiments, platform 120 may further provide intelligent management and distribution of alerts based on factors such as care provider and / or caregiver proximity, shift timing, qualifications, cost-effectiveness (e.g., caregiver’s hourly rate), current workload, and potential imminent care needs elsewhere, leading to efficient assignment of caregiver tasks where possible. As an example, a first sensor may detect that medication has been missed for a patient, and a second sensor detects that a continence pad needs changing soon.Platform 120 identifies one or more of the following information: where the carers are, their qualifications, their permissions and knowledge, what supplies they have with them, whether they are likely to be needed somewhere else (or are going off shift) soon, and / or how much they cost. Using such information, platform 120 selects one or more care providers and requests them to attend to the patient needs (administering medication, checking medication dispenser, and changing continence pad). In one embodiment, the caregiver may accept or reject the request via (1) the desktop, mobile app, or tablet user interfaces, (2) speaking to a smart speaker transmitting the request, (3) sending a SMS responding to the request, (4) speaking to a robotic call responding to the request, or (5) pressing a key on a telephone handset or mobile phone to respond to a robotic call.

[0139] In some embodiments, platform 120 may be utilized to optimize medication management in patient care, including dispensing medications using devices with integrated technology to track medication compliance. Notifications and reminders may be provided to caregivers and seniors to ensure medication adherence. Finally, medication data may be integrated into platform 120 for comprehensive monitoring and reporting.

[0140] In some embodiments, platform 120 may be used to optimize patient safety. Wearable sensors, presence sensors, GPS trackers, radar-based sensors to detect an incapacitated person, and / or location sensors may be utilized to detect and alert care providers of potential safety hazards, such as falls or wandering. For example, real-time notifications and alerts may be generated so that care providers may be notified of safety hazards and can intervene in a timely manner. Finally, historical data may also be analyzed to identify patterns and trends for proactive safety measures.

[0141] In some embodiments, platform 120 may be used to improve patient nutrition. Sensors may be used to monitor hydration, dietary habits, nutritionalintake through sensors in the kitchen and / or wearable sensors and devices. Connected food scales, food purchases and urine / stool monitoring may also be tracked in some embodiments. Platform 120 may be integrated with a senior living center food and beverage system to track food consumption in senior care facilities, or may take data from a care management system into which a caregiver has entered a VIP or senior’s food and beverage intake. In addition, some embodiments may perform urine / stool monitoring using sensors that analyze urine as it passes into the toilet, and / or that analyze images of stools when they are in the toilet. This data may be combined with other health care data such as activity, sleep, heart rate, medications prescribed, and medication compliance. Nutrition data may be integrated into platform 120 with other patient data as discussed above to track and analyze patient dietary patterns. Personalized nutritional recommendations and / or food and drink purchase options may be provided to care providers and patients based on the data collected.

[0142] Methods for increasing caregiver productivity in VIP and senior care are disclosed in some embodiments. Information gathered using the fixed sensors, wearables, devices, hardware and software described above may be combined with any of the following to improve caregiver productivity: (1) information about the needs and preferences of VIPs, (2) information about the skills and qualifications of the caregivers that are on shift, (3) information about the current location of the on-shift caregivers relative to the VIPs, (4) information about the relative importance and the length of time needed for an on-shift caregiver to complete a currently assigned task, (5) information about the current needs of other VIPs, and (6) information about the likely needs of other VIPs over the coming hours. Based on this information, methods disclosed herein may instruct one or more particular caregivers to a task to attend to the care needs of a particular VIP, and may wait to see who accepts this task before informing the other VIPs. Methods and systems disclosed herein may alsoestimate and / or provide recommendations as to whether and when the instructed care intervention was performed, and by whom.

[0143] In some embodiments, platform 120 provides recommendations and / or areas for improvement at the care facility level, caregiver organization level, and / or individual caregiver level. In some embodiments, senior living operators who oversee multiple care facilities or communities, may benefit from data- driven insights powered by platform 120 to enhance operational efficiency and effectiveness.

[0144] Platform 120 collects and compares data from multiple care facilities that operate under a single senior living operator to help benchmark each care facility and share best practices among various care facilities. Types of data collected may include, but are not limited to frequency and types of alerts, time elapsed until a care provider responds to an alert, time elapsed until an alert is resolved, medication compliance levels, wandering and fall incidents (e.g., number of incidents, location of incidents, time(s) of incidents, individuals who fell, etc.), and sleep quality. Data collected may comprise or be used to generate performance metrics for one or more care facilities. By comparing the performance metrics of each care facility, platform 120 may identify which care facilities overseen by the senior living operator may outperform the other care facilities of the senior living operator in specific areas. For instance, one facility may have significantly lower alert response times due to certain operational practices or the use of specific technologies. In another example, a care facility may have less night time falls due to certain “best in class” operational practices. In these examples, the senior living operator can recognize these best practices and can consider implementing these operational practices across the other care facilities to elevate the overall performance and the level of care. Conversely, underperforming facilities can be provided with necessary resources or interventions to improve the quality of care.

[0145] In some embodiments, platform 120 analyzes staff performance metrics across different facilities operated by one or more senior living operators. Staff performance metrics may include data on individual caregiver performance, alert response performance time, etc. In some cases, patterns might emerge over time showing that certain care facilities have an abundance of highly trained staff in areas where the need is relatively low, while other care facilities may have a shortage of trained staff. Similarly, if a care facility has fewer alerts or issues in a particular area (e.g., medication management or fall incidents), and it correlates with higher training levels in that area, it suggests that such training is highly effective. In such cases, trained staff may be reallocated or redistributed from facilities having an abundance of trained staff, to other care facilities experiencing a shortage of trained staff. Using the data and insights provided by platform 120, a senior living operator can make informed decisions about redistributing staff to match the needs of each facility more closely. Effective training programs may also be standardized across different care facilities to help ensure consistent care quality. By aggregating and analyzing data from multiple facilities, platform 120 thus provides senior living operators with a birds-eye view of operations, and assists senior living operators with making strategic decisions that enhance overall care quality and operational efficiency of the senior living operator.

[0146] In additional embodiments, platform 120 may be integrated with inventory systems to monitor equipment and supply usage rates, in correlation with patient needs and alerts. Over time, patterns may emerge showing that certain supplies are being used up more quickly than expected, or that certain supplies are being used more slowly than expected, or are not being used at all. This allows for optimized procurement, minimizing waste, detecting supply shrinkage, and ensuring that necessary supplies are always in stock.

[0147] The embodiments discussed above illustrate the breadth of functionality in platform 120, including a comprehensive approach to enhancingcare provider productivity and effectiveness when caring for seniors and other patients, including those in residential care facilities. In some embodiments, platform 120 provides insights from data to support effective management of caregiver teams working in the homes of VIPs and seniors to ensure optimal team performance and maintain high quality care.

[0148] In some embodiments, platform 120 records the number of alerts and insights generated by the platform 120, and their corresponding response times for different teams and shifts. Such data can be combined with data about the number of caregivers available, their skill levels, and the number of VIPs being cared for during each shift. Platform 120 may therefore present information such as certain shifts consistently having slower response times to alerts, which could indicate understaffing, or that a particular shift is more challenging due to the nature of care required during those hours. In response, platform 120 may guide the caregiver team’s manager to consider adjusting staff allocations, such as ensuring that more experienced caregivers are available during challenging shifts, or bringing in additional support and staffing during peak times. This ensures that VIPs get timely attention, reducing risks, and improving overall quality of care. In some embodiments, machine learning algorithms similar to those described above for generating insights and alerts, may be applied across response time data to insights and alerts to suggest areas and shifts that may require additional staffing.

[0149] In additional embodiments, platform 120 uses data on the types of alerts that are frequently generated and the outcomes post-intervention, and pairs this data with caregiver profiles that detail the caregiver’s training history, areas of specialty, and feedback from the VIP or senior to provide information to enhance training and skills enhancement for caregivers. For example, if a pattern emerges for a caregiver team where specific types of alerts (e.g., related to medication management) are not addressed effectively, it could highlight a knowledge or training gap within the caregiver team. Conversely, if certaincaregivers consistently address these issues effectively, it might indicate that specialized training or skills should be shared with the whole caregiver team. In such examples, the caregiver team manager could prioritize additional training sessions or workshops focusing on identified areas where specialized training or skills are needed. Caregiver team managers may also facilitate peer-to-peer learning, where experienced care providers share their expertise with the rest of the caregiving team. Thus, data analytics capabilities of platform 120 may be leveraged at the caregiver team management level to promptly identify and address areas of improvement, thus leading to better care coordination, timely interventions, and ultimately enhanced VIP and senior well-being.

[0150] In some embodiments, platform 120 may support improvement of individual caregiver performance, thus enhancing the quality of care provided to VIPs and seniors, and fostering personal growth and job satisfaction for the caregiver. Platform 120 tracks the time taken by individual caregivers to address and resolve alerts and insights. This data is paired with the nature of the alert or insight, the location of the affected VIP or senior, and the frequency of alerts during a caregiver’s shift. If platform 120 finds that a particular caregiver consistently takes longer than the average response time to attend to specific types of alerts, it could highlight a training need or an issue with workload distribution. Caregiver managers can have one-on-one discussions to understand any challenges an individual caregiver might be facing. Perhaps the individual caregiver needs more training in certain care areas, or may be their shift has them located far from where most of their alerts originate, thus indicating a need for reassignment of caregivers.

[0151] In some embodiments, platform 120 further collects feedback postresolution of an alert or insight to help improve individual caregiver performance. Such feedback includes data from other care providers and staff who collaborated on the resolution, and includes calculations of efficiency, effectiveness (e.g., number and experience level of care providers need to respondto an alert, time to resolution, supplies needed, number of alerts generated and / or resolved for the VIP within a given time period preceding and / or following the alert, etc.). For example, if a caregiver consistently has difficulty effectively resolving certain types of issues, it can be a cue for (1) targeted training or mentorship of the caregiver, (2) evaluation of whether the VIP or senior has an optimal care plan or if adjustments are needed, and / or (3) whether there are sufficient care resources being made available to work alongside this particular care provider. Caregiver managers may then curate specific training modules, pair the caregiver with a partner or mentor, or even suggest shadowing more experienced caregivers to enhance their skills. In such embodiments, analytical capabilities of platform 120 may enable individual caregivers to not only receive assistance in their immediate duties, but also gain insights that can help build their professional development and proficiency. Improving individual caregiver performance thus ultimately leads to better care outcomes for VIPs and seniors and a more rewarding work environment for the individual caregivers.

[0152] FIG. 5 illustrates a graphical user interface (GUI) of a caregiver overview dashboard screen 500 according to some embodiments. Dashboard screen 500 comprises a plurality of status blocks, each of which corresponds to an individual patient and provides information on the last event, and followed by one or more rows of status icons regarding the current status of various sensors and / or checks corresponding to the individual patient. Finally, a number of active alerts may also be displayed. For example, status block 510 corresponds to an individual named “Kailey Bowen”. Status block 520 corresponds to an individual named “Johan Short”. Further details of status blocks 510 and 520 may be discussed below with respect to FIGs. 6, 7 and 8.

[0153] These status blocks utilize easily identifiable icons to consolidate dissimilar and previously unconnected data (e.g., medication compliance, sleep quality, and pain levels), enabling care providers to monitor important vital data at a glance. This capability enhances understanding of cause-effectrelationships, provides early insights into particular conditions, perhaps before symptoms develop, and helps monitor progress towards alert thresholds. Several exemplary status icons are discussed below in connection with various sensors that may be used in conjunction with a particular patient and that patient’s living environment. A variety of other icons corresponding to other types of sensors not depicted in FIGs. 6 — 8 may also be used and are included within the scope of embodiments of the disclosed invention.

[0154] FIG. 6 illustrates a GUI of an exemplary first dashboard status block 600 for an individual patient according to some embodiments. Here there is a patient named “Lea Sosa” located in Room 456. The last event was on the current day, at 6:45 a.m. There are 92 open alerts for Lea Sosa. Her “at home” icon 610, which may be triggered by a wearable device, indicates that she is at home (since it shows a house with a person inside), and that the status is normal (green). Cardiac icon 620 and hazard icon 630 indicate a status that a check is needed (icons are colored orange) for these items. Medication icon 640 indicates that the medication dispenser is current (filled, showing three pills / tablets), and that the patient Lea Sosa is up to date on her medications (icon is colored green). Continence icon 650 indicates that it is clean (briefs show white color, no change of diaper needed), and the check is up to date (icon is colored green). Possible fall icon 660 is colored red, indicating that a care provider should check in on Lea Sosa in case of a possible fall. Bed icon 680 indicates a status that a check is needed (icon is colored orange) and that the patient is not in bed. Patient (VIP - Vulnerable Independent Person) check icon 670 is orange, indicating that a patient check for Lea Sosa is overdue, and the text below icon 670 indicates that a check was due 1 hour and 24 minutes ago. In addition, a user may hold a mouse or touch any icon 610 — 680, and a small box of relevant information (not shown) describing the icon and the current status will appear.

[0155] FIG. 7 illustrates a GUI of a second dashboard status block 700 for the same individual patient, “Lea Sosa”, according to some embodiments. The name,location, last event and number of open alerts are unchanged from the status shown in FIG. 6. The at home (green) 710, cardiac monitor (orange) 720, and hazard (orange) icons 730 are unchanged from FIG. 6. Medication icon 740 shows some pills missing as compared to the medication icon 640 in FIG. 6, indicating that the VIP has missed a medication dose for some reason, and that a caregiver has closed the 'missed medication' alert, and the patient is up to date on taking her medications (icon is colored green). Continence icon 750 indicates that the continence pad is partially filled as compared to the status of the pad shown in FIG. 6, and is the status is up to date (colored green). Possible fall icon 760 status remains unchanged from FIG. 6. Bed icon 780 is unchanged from FIG. 6 and indicates a status that a check is needed (icon is colored orange) and that the patient is not in bed. VIP Status check icon 770 is grey, indicating that a patient check sensor / time is not currently connected or due.

[0156] FIG. 8 illustrates a GUI of a third dashboard status 800 for the same individual patient “Lea Sosa” from FIGs. 6 and 7, according to some embodiments. The name, location, last event and number of open alerts are unchanged from the status shown in FIGs. 6 and 7. The at home (green) 810 icon shows that the patient is not at home. Cardiac monitor (orange) 820, and hazard (orange) icons 830 are unchanged from FIGs. 6 and 7. Medication icon 840 still shows some pills missing as compared to the medication icon 640 in FIG. 6, indicating that the VIP has missed a medication dose for some reason, and that a caregiver has not yet closed the 'missed medication' alert, and the patient is behind on taking her medications (icon is colored orange). Continence icon 850 indicates that the continence pad is clean as compared to the status of the pad shown in FIG. 6, and the status check is overdue (colored orange). Possible fall icon 860 status is now orange, indicating that a status check may be overdue, but not urgent (red), as it was in FIGs. 6 and 7. Bed icon 680 indicates a status that a check is needed (icon is colored orange) and that the patient is now in bed.VIP Status check icon 870 is now green, indicating that a patient check sensor / time is up to date, and will be due in 4 minutes.

[0157] FIG. 9 illustrates a graphical user interface (GUI) of an initial daily summaries screen 900 according to some embodiments. The daily summaries screen 900 shows a legend 910 that shows color codes for daily summaries 920, 930, and 940 that show a 24-hour timeline, in the “Overview” view, for February 16, 2023 (current day); February 15, 2023 (previous day); and February 14, 2023, respectively. In some embodiments, there are color codes for the following patient status indicators: “Awake in bed”, “Asleep”, “Out of bed”, “At home”, “May be away from home”, and point in time indicators for “Events (circular dots), “Alert” (triangles), and “Scheduled Carer Visit” (ovals) for care provider visits. Events may comprise events registered by sensors in the patient’s residence or worn on the patient’s body. For example, events registered by sensor may include in some embodiments the following events: dispensing medication, turning the tea kettle on, getting out of bed, going to the bathroom, using a walking aid. The current day shows no more status after 6 a.m., since 6 a.m. represents the current time of day that the screenshot was taken.

[0158] FIG. 10 illustrates a GUI of a first transition screen 1000 showing a first alert 1050 according to some embodiments. Similar to FIG. 9, The daily summaries screen 1000 in FIG. 10 shows a legend 1010 that shows color codes for daily summaries 1020, 1030, and 1040 that show a 24-hour timeline, in the “Overview” view, for February 16, 2023 (current day); February 15, 2023 (previous day); and February 14, 2023, respectively. In some embodiments, there are color codes for the following patient status indicators: “Awake in bed”, “Asleep”, “Out of bed”, “At home”, “May be away from home”, and point in time indicators for “Events (circular dots), “Alert” (triangles), and “Scheduled Carer Visit” (ovals) for care provider visits. Events may comprise events registered by sensors in the patient’s residence or worn on the patient’s body. For example, events registered by sensor may include in some embodiments the followingevents: dispensing medication, turning the tea kettle on, getting out of bed, going to the bathroom, using a walking aid. The current day shows no more status after 6 a.m., since 6 a.m. represents the current time of day that the screenshot was taken.

[0159] A cursor is shown positioned over near the 6 a.m. time position on the February 16, 2023 timeline, where a notification box 1050 appears, showing that where the user has positioned the cursor 1055, from 5:46 a.m. - 6:00 a.m., the patient John Smith is “Out of bed at night.” The color code shows red, which indicates “Out of bed” according to legend 1010. There are events (blue circular dots) around the red color band for that period, indicating events (such as movement during sleep, snoring, heart rate changes, and / or sleep cycle tracking) that were possibly noted by a connected sleep mat (e.g., as manufactured by Withings). A connected sleep mat or similar device may detect that the patient is out of bed.

[0160] FIG. 11 illustrates a GUI of a second transition screen 1100 showing a second alert according to some embodiments. Similar to FIGs. 9 and 10, the daily summaries screen 1100 in FIG. 11 shows a legend 1110 that shows color codes for daily summary 1120, 1130, and 1140 that show a 24-hour timeline, in the “Overview” view, for February 16, 2023 (current day); February 15, 2023 (previous day); and February 14, 2023, respectively. In some embodiments, there are color codes for the following patient status indicators: “Awake in bed”, “Asleep”, “Out of bed”, “At home”, “May be away from home”, and point in time indicators for “Events (circular dots), “Alert” (triangles), and “Scheduled Carer Visit” (ovals) for care provider visits. Events may comprise events registered by sensors in the patient’s residence or worn on the patient’s body. For example, events registered by sensor may include in some embodiments the following events: dispensing medication, turning the tea kettle on, getting out of bed, going to the bathroom, using a walking aid. The current day shows no morestatus after 6 a.m., since 6 a.m. represents the current time of day that the screenshot was taken.

[0161] A cursor is shown positioned over near the 4 p.m. time position on the February 15, 2023 timeline 1130, where a notification box 1150 appears, showing that where the user has positioned the cursor 1155, for a portion of the timeline having a time range from 4:27 p.m. - 5: 18 p.m., the patient John Smith “May be away from home.” The color code shows diagonal yellow stripes, which indicates “May be away from home” according to legend 1110. There are events (blue circular dots) around the yellow striped color band for that period, indicating events that were possibly noted by an open-door sensor or wearable location sensor or similar device detecting that the patient may have left the home, and then may have subsequently returned home.

[0162] FIG. 12 illustrates a GUI of a third transition screen 1200 showing a third alert according to some embodiments. Similar to FIGs. 9 — 11, the daily summaries screen 1200 in FIG. 12 shows a legend 1210 that shows color codes for daily summary 1220, 1230, and 1240 that show a 24-hour timeline, in the “Overview” view, for February 16, 2023 (current day); February 15, 2023 (previous day); and February 14, 2023, respectively. In some embodiments, there are color codes for the following patient status indicators: “Awake in bed”, “Asleep”, “Out of bed”, “At home”, “May be away from home”, and point in time indicators for “Events (circular dots), “Alert” (triangles), and “Scheduled Carer Visit” (ovals) for care provider visits. Events may comprise events registered by sensors in the patient’s residence or worn on the patient’s body. For example, events registered by sensor may include in some embodiments the following events: dispensing medication, turning the tea kettle on, getting out of bed, going to the bathroom, using a walking aid. The current day shows no more status after 6 a.m., since 6 a.m. represents the current time of day that the screenshot was taken.

[0163] A cursor is shown positioned over near the 9 a.m. time position on the February 15, 2023 timeline, where a notification box 1250 appears, showing that where the user has positioned the cursor 1255, at the Alert (orange triangle) at 9 a.m., the patient John Smith may have an alert notification of “Late waketime. It is 9:00 am and Amba has detected John is still in bed.” The orange triangle is where the cursor is positioned, which indicates “Alert” according to legend 1210. The alert and notification may possibly be noted and / or triggered by a connected sleep mat, and / or wearable location sensor, sleep sensor, CPAP device or similar device detecting that the patient is still lying in the bed and possibly asleep.

[0164] FIG. 13 illustrates a GUI of a fourth transition screen 1300 showing a table view 1330 for Wednesday, 15 February 2023 according to some embodiments. Similar to FIGs. 9 — 12, the daily summaries screen 1300 in FIG. 13 shows a legend 1310 that shows color codes for daily summaries 1320 and 1340 that show a 24-hour timeline, in the “Overview” view, for February 16, 2023 (current day) and February 14, 2023, respectively. In some embodiments, there are color codes for the following patient status indicators: “Awake in bed”, “Asleep”, “Out of bed”, “At home”, “May be away from home”, and point in time indicators for “Events (circular dots), “Alert” (triangles), and “Scheduled Carer Visit” (ovals) for care provider visits. Events may comprise events registered by sensors in the patient’s residence or worn on the patient’s body. For example, events registered by sensor may include in some embodiments the following events: dispensing medication, turning the tea kettle on, getting out of bed, going to the bathroom, using a walking aid. The current day shows no more status after 6 a.m., since 6 a.m. may be the current time of day that the screenshot was taken.

[0165] For February 15, 2023 (previous day), a “Table” view is highlighted, and a table view 1330 is displayed, showing a breakdown of the timeline into “In bed” time 1350, and events (shown by blue circular dots) detected at the “Front Door”, “Livingroom”, and “Bathroom” 1360. Such events may possibly be notedby a door sensor or wearable location sensor or similar device detecting that the patient may have entered a room and left a room, such as the living room or bathroom. Other detected events may include registering when the front door was opened and / or closed, and / or registering when the patient may have left the home and subsequently returned home. The in bed time may possibly be recorded in some embodiments by a connected sleep mat, and / or wearable location sensor, sleep sensor, CPAP device or similar device detecting that the patient is still lying in the bed, and whether the patient is awake and in bed, or in bed and asleep.

[0166] FIG. 14 illustrates a GUI of an initial analytics screen 1400 showing analytics in a graphical form with colors according to some embodiments. Analytics screen 1400 enables dissimilar (but related) information to be presented on the same chart or graph in a meaningful way. For example, sleep score, nighttime bathroom visits, and number of daily steps may be depicted together on a single graph. A care provider may view a single screen to see a summary of all gathered sensor data (or selected sensor data) depicted on a graph for a particular time period. In some embodiments, a care provider may be able to see at a glance which measures are getting close to levels of concern, and / or crossing over into alert territory by seeing if the measures are within the orange bands at the top and the bottom of graph 1420. In some embodiments, the orange bands correspond to the upper and lower limits for a particular measure that a care provider has set for a particular individual.

[0167] In one embodiment as shown in FIG. 14, analytics for a patient named John Smith are shown for a period from February 2 to February 15. In box 1410, analytics may be filtered by Health, Sleep, and Activity, for example. In graph 1420, analytics (as selected by the care provider for display) shown include: average sleeping heart rate, sleep duration, sleep score, time in bed, room humidity, and room temperature in the living room. In graph 1420 of FIG. 14,the graph lines are depicting using colors in accordance with the legend 1430 for graph 1420.

[0168] FIG. 15 illustrates a GUI of a first transition screen 1500 showing analytics in a graphical form with colors according to some embodiments. As in FIG. 14, Analytics screen 1500 enables dissimilar (but related) information to be presented on the same chart or graph in a meaningful way. For example, sleep score, nighttime bathroom visits, and number of daily steps may be depicted together on a single graph. A care provider may view a single screen to see a summary of all gathered sensor data (or selected sensor data) depicted on a graph for a particular time period. In some embodiments, a care provider may be able to see at a glance which measures are getting close to levels of concern, and / or crossing over into alert territory by seeing if the measures are within the orange bands at the top and the bottom of graph 1520. In some embodiments, the orange bands correspond to the upper and lower limits for a particular measure that a care provider has set for a particular individual.

[0169] In one embodiment as shown in FIG. 15, analytics for a patient named John Smith are shown for a period from February 2 to February 15. In box 1510, analytics may be filtered by Health, Sleep, and Activity, for example. A dropdown menu 1540 to filter analytics by “Health” metrics is shown in box 1410 where a user (e.g., a care provider) has selected a “Nighttime Bathroom Visits Daily Count”. In graph 1520, analytics (as selected by the care provider for display) shown include: average sleeping heart rate, sleep duration, sleep score, time in bed, room humidity, and room temperature in the living room. The “Nighttime Bathroom Visits Daily Count” metric is not yet depicted in graph 1520, as the user has just selected this metric. In graph 1520 of FIG. 15, the graph lines are depicting using colors in accordance with the legend 1530 for graph 1520.

[0170] FIG. 16 illustrates a GUI of a second transition screen 1600 showing analytics in a graphical form with colors and a filter selection by nighttime bathroom visits daily count according to some embodiments. As in FIGs. 14 and 15, Analytics screen 1600 enables dissimilar (but related) information to be presented on the same chart or graph in a meaningful way. For example, sleep score, nighttime bathroom visits, and number of daily steps may be depicted together on a single graph. A care provider may view a single screen to see a summary of all gathered sensor data (or selected sensor data) depicted on a graph for a particular time period. In some embodiments, a care provider may be able to see at a glance which measures are getting close to levels of concern, and / or crossing over into alert territory by seeing if the measures are within the orange bands at the top and the bottom of graph 1620. In some embodiments, the orange bands correspond to the upper and lower limits for a particular measure that a care provider has set for a particular individual.

[0171] In one embodiment as shown in FIG. 16, analytics for a patient named John Smith are shown for a period from February 2 to February 15. In box 1610, analytics may be filtered by Health, Sleep, and Activity, for example. Now, in menu bar 1640 a count of 1 “Health” metric is shown in box 1610, where a user (e.g., a care provider) has selected a “Nighttime Bathroom Visits Daily Count”. In graph 1620, analytics (as selected by the care provider for display) shown include: nighttime bathroom visits daily count, average sleeping heart rate, sleep duration, sleep score, time in bed, room humidity, and room temperature in the living room. The “Nighttime Bathroom Visits Daily Count” metric is now shown in graph 1620, as the user selected this metric in the prior transition screen of FIG. 15. In graph 1620 of FIG. 16, the graph lines are depicting using colors in accordance with the legend 1630 for graph 1620.

[0172] FIG. 17 illustrates a GUI of a third transition screen 1700 showing analytics in a graphical form with shapes and dashes and a filter selection by nighttime bathroom visits daily count according to some embodiments. As inFIGs. 14-16, Analytics screen 1700 enables dissimilar (but related) information to be presented on the same chart or graph in a meaningful way. A care provider may view a single screen to see a summary of all gathered sensor data (or selected sensor data) depicted on a graph for a particular time period. In some embodiments, a care provider may be able to see at a glance which measures are getting close to levels of concern, and / or crossing over into alert territory by seeing if the measures are within the orange bands at the top and the bottom of graph 1720. In some embodiments, the orange bands correspond to the upper and lower limits for a particular measure that a care provider has set for a particular individual.

[0173] In one embodiment as shown in FIG. 17, analytics for a patient named John Smith are shown for a period from February 2 to February 15. In box 1710, analytics may be filtered by Health, Sleep, and Activity, for example. A count of 1 “Health” metric, 4 “Sleep” metrics, and 2 “Activity” metrics are shown in box 1710. In graph 1720, analytics (as selected by the care provider for display) shown include: nighttime bathroom visits daily count, average sleeping heart rate, sleep duration, sleep score, time in bed, room humidity, and room temperature in the living room. The user has toggled the graph controls 1740 to show “Shapes & Dashes” rather than “Colours.” Thus, in graph 1720 of FIG. 17, the graph lines are depicting using shapes and dashes in accordance with the legend 1730 for graph 1720.

[0174] FIG. 18 illustrates a GUI of a fourth transition screen 1800 showing analytics in a graphical form with colors and a filter selection to selected properties according to some embodiments. As in FIGs. 14-17, Analytics screen 1800 enables dissimilar (but related) information to be presented on the same chart or graph in a meaningful way. A care provider may view a single screen to see a summary of all gathered sensor data (or selected sensor data) depicted on a graph for a particular time period. In some embodiments, a care provider may be able to see at a glance which measures are getting close to levels of concern,and / or crossing over into alert territory by seeing if the measures are within the orange bands at the top and the bottom of graph 1820. In some embodiments, the orange bands correspond to the upper and lower limits for a particular measure that a care provider has set for a particular individual.

[0175] In one embodiment as shown in FIG. 18, screen 1800 has transitioned back to the screen shown in FIG. 16, after the user has toggled the graph controls 1840 back to show “Colours” rather than “Shapes & Dashes”. Thus, the settings in box 1810, legend 1830 are the same as in FIG. 16. Also, graph 1820 of FIG. 18 is the same as shown in graph 1620 of FIG. 16.

[0176] FIG. 19 illustrates a GUI of a fifth transition screen 1900 showing analytics in a graphical form with colors and a filter selection to selected properties with a cursor highlighting a nighttime bathroom visits daily count for one night according to some embodiments. As in FIGs. 14-18, analytics screen 1900 enables dissimilar (but related) information to be presented on the same chart or graph in a meaningful way. A care provider may view a single screen to see a summary of all gathered sensor data (or selected sensor data) depicted on a graph for a particular time period. In some embodiments, a care provider may be able to see at a glance which measures are getting close to levels of concern, and / or crossing over into alert territory by seeing if the measures are within the orange bands at the top and the bottom of graph 1920. In some embodiments, the orange bands correspond to the upper and lower limits for a particular measure that a care provider has set for a particular individual.

[0177] In one embodiment as shown in FIG. 19, analytics for a patient named John Smith are shown for a period from February 2 to February 15. In box 1910, analytics may be filtered by Health, Sleep, and Activity, for example. A count of 1 “Health” metric, 4 “Sleep” metrics, and 2 “Activity” metrics are shown in box 1910. In graph 1920, analytics (as selected by the care provider for display) shown include: nighttime bathroom visits daily count, average sleeping heartrate, sleep duration, sleep score, time in bed, room humidity, and room temperature in the living room. The user has selected the graph plot 1950 for the Nighttime Bathroom Visits Daily Count metric using a mouse, making the other graph plots in graph 1920 lighter to fade into the background, while graph plot 1950 remains the same dark shade. The user has also moved cursor 1960 to point to a local maxima on the “Nighttime Bathroom Visits Daily Count” graph plot 1950. Hovering cursor 1960 over the local maxima makes visible information text box 1940 to show a count of 12 for “Nighttime Bathroom Visits Daily Count on Friday, 10 February at 11:19 am.” Furthermore, in graph 1920 of FIG. 19, the graph lines are depicted using colors in accordance with the legend 1930.

[0178] FIG. 20 illustrates a GUI of a sixth transition screen 2000 showing analytics in a graphical form with colors and a filter selection to only properties with alerts according to some embodiments. As in FIGs. 14-19, analytics screen 2000 enables dissimilar (but related) information to be presented on the same chart or graph in a meaningful way. A care provider may view a single screen to see a summary of all gathered sensor data (or selected sensor data) depicted on a graph for a particular time period. In some embodiments, a care provider may be able to see at a glance which measures are getting close to levels of concern, and / or crossing over into alert territory by seeing if the measures are within the orange bands at the top and the bottom of graph 2000. In some embodiments, the orange bands correspond to the upper and lower limits for particular measure that a care provider has set for a particular individual.

[0179] In one embodiment as shown in FIG. 20, analytics for a patient named John Smith are shown for a period from February 2 to February 15. In box 2010, analytics may be filtered by Health, Sleep, and Activity, for example. However, in FIG. 20, the user has elected not to manually select properties (e.g., measurement data) for display, but has selected to display “Only properties with alerts” in accordance with radio button selection menu 2040. A count of 0“Health” metrics, 2 “Sleep” metrics, and 0 “Activity” metrics are shown in box 2010. In graph 2020, analytics (as selected by the care provider for display) shown include only the 2 properties with alerts for John Smith: out of bed count, and time in bed. In graph 2020 of FIG. 20, the graph lines are depicted using colors in accordance with the legend 2030.

[0180] The analytics in FIGs. 14-20, in some embodiments, may be used to choreograph the behavior of devices and care providers to enhance efficiency, effectiveness, and quality of care. For example, in one embodiment, when a patient gets out of bed (sensor) or arrives in their kitchen (sensor), a medication dispenser may be programmed to ring or buzz, in addition to or instead of at a pre-programmed time. In some embodiments, platform 120 may send a reminder via loudspeaker into the patient’s residence, to the patient to use their walking aid (sensor to detect walking aid use) as they start getting out of bed at night (sensor), and remind them again if the patient does not appear to be using it.

[0181] In some embodiments as discussed above, platform 120 may provide alerts to indicate a patient needs assistance (e.g., missed medication, out of bed and not using walking aid, continence pad needs changing). Platform 120 may provide in some embodiments the ability to aggregate alerts, thereby enabling consolidation of care tasks to a single visit, thus optimizing the caregiver’s time and minimizing the disturbances to the patient. For example, if a patient is out of bed, and needs to be visited to be helped back in, platform 120 may also identify that a continence pad will need changing soon, and / or that a medication is due to be taken soon, so a care provider will be assigned and instructed accordingly to take care of all the above tasks in a single visit, e.g., giving the patient their medication and changing the patient’s continence pad before putting the patient back to bed. In some examples, alert settings can be set for each patient or resident according to issues of particular concern. For example, alert settings may be established for each resident or patient in discussion with caregivers, medical care professionals, and / or family members, according to theissues they were concerned about. Additional generic alerts can, in some examples, be made active automatically to indicate changes from normal levels which are measured the first few (e.g., two) weeks that a resident or patient has platform 120 deployed in their living space.

[0182] In one example embodiment, platform 120 can be implemented in a care home or senior living facility to help enhance the safety and well-being of its residents. For example, platform 120 can be deployed to reduce falls among high- risk residents through advanced monitoring and alerting mechanisms. Thus, example systems, apparatuses, and methods described herein can be shown to lead to a significant reduction in falls, improved staff efficiency, and enhanced resident safety, thus demonstrating the effectiveness of integrating technology to augment human support in residential care settings.

[0183] In particular, fall management using traditional methods such as sensor mats and physical checks has been shown to have significant limitations, particularly for residents or patients identified as high-risk for falling. For example, sensor mats may not be completely reliable, as some residents can bypass the sensor mats, leading to unmonitored bed exits. Additionally, sensor mats can pose a trip hazard to some residents. In addition, having staff conduct regular physical checks on high-risk residents, e.g., every 30 minutes, is a labor- intensive process that can be challenging to maintain consistently and is disruptive to the residents and patients. Thus, the traditional approach, although diligent, sometimes can lead to delayed responses, where the first indication of a fall is the sound of the fall itself, or the next scheduled physical check.

[0184] One example implementation of platform 120 can enhance fall detection and response times using a real-time alerting mechanism as described herein. In such an example embodiment, platform 120 can include at least the following components: sleep monitoring devices, motion sensors, and doorsensors. Sleep monitoring devices track residents’ movements in bed and alert staff promptly when a resident leaves the bed. Motion sensors installed in residents’ rooms and adjoining areas such as bathrooms detect movement of residents and trigger alerts to staff using platform 120. Similarly, door sensors monitor door activity, providing additional context to the residents’ movements. Such example implementations of platform 120 works to promptly inform staff when a resident is at risk, thereby allowing staff to respond more swiftly and effectively.

[0185] Such an example implementation, in one embodiment, is shown to have a dramatic reduction in nighttime falls. For example, prior to installation of the example implementation of platform 120, one care facility located in the United Kingdom recorded 44 falls in a particular month. After an example implementation of platform 120 was installed as described above, the number of falls at this same facility dropped to 9 the following month, representing a 79% reduction. This substantial decrease highlights the effectiveness of implementations of platform 120 in mitigating fall risks. In this embodiment, detailed analysis was conducted to identify if any other variables could have contributed to this improvement, but the analysis showed that introduction of the platform 120 example implementation supported more proactive action by staff, leading to the dramatic reduction in the number of resident falls and enhancing resident safety. The primary alert which in the example implementation has made a significant difference is the nighttime bed exit alert. Caregivers are alerted immediately if a patient exits the bed at nighttime, allowing a caregiver to promptly attend to a patient as this can indicate an issue of concern. Other relevant alerts include a relatively Low Sleep Score (indicated that a resident has had a bad night’s sleep) and relatively High Sleeping Heart Rate (indicating early signs of a possible infection). Both of these alerts suggest an increased risk of falling and therefore suggest that increased caregiver vigilance in checking on the affected residents or patients is needed. Thisreduction in falls directly impacts residents’ well-being, reducing the incidence of injuries and the need for emergency medical interventions. Furthermore, this example implementation of platform 120 has allowed staff to monitor residents without constant physical intrusion, thus promoting resident independence and creating a more comfortable and secure environment for residents.

[0186] Furthermore, this example implementation of platform 120 was shown to significantly reduce the need for continuous physical checks of residents, the alleviating the staff workload. With real-time alerts, staff can focus on immediate risks and planned care and support rather than routine physical checks, leading to a more efficient allocation of staff time and resources. Staff feedback of the example implementation of platform 120 indicates that the reduction in manual routine checks decreased staff stress levels, allowing the staff to provide a higher overall quality of care. Further improvements of the example implementation of platform 120 can monitor and adapt the system to further reduce falls during daytime (in addition to the reduction in nighttime) falls and in communal areas. In addition, further enhancements to the example implementation of platform 120 can integrate platform 120 with existing care management systems, to reduce the duplication of records and streamline the documentation process at the care facility. Thus, this example implementation of platform 120 demonstrates a significant positive impact in augmenting human support in care settings. The significant reduction in falls, improved staff efficiency, and enhanced resident safety underscore the value of integrating advanced monitoring systems in care facilities.

[0187] In another example implementation of platform 120 in an integrated retirement community in the United States (combining independent living, assisted living, and memory care), care quality has shown significant improvement since installation of platform 120. For example, resident falls have similarly declined from month to month since the installation of platform 120. Rates of re -hospitalization of residents have decreased. Sensors that can be usedin the example implementation of platform 120 to reduce hospitalizations can include an electronic medication dispenser which reminds residents to take their medications and alerts a caregiver if they miss taking medications. In such an example, the caregiver can see if the resident is at home or in bed, and decide whether to call or visit the patient to check on them to ensure there are not issues, and / or remind them to take their medications. Another example of sensors that can be used to help reduce hospitalizations can include a continence sensor which detects that a continence pad needs changing and can reduce skin irritation and infection, which can be a leading cause of hospitalization.

[0188] Furthermore, the impact on administration of psychotropic drugs has also decreased by over 50%. Factors in the reduction of psychotropic drug use can be directly attributed to implementation of platform 120 as it provides information to caregivers which can help explain certain behaviors of residents or patients (e.g., disruptive behavior of resident or patient during certain times of the day can be caused by factors such as: poor sleep at night, infection symptoms, too much sleep in the daytime, not getting enough exercise). In such example implementations, the caregiver can use the information provided by platform 120 to make interventions to address these issues of concern before resorting to psychotropic drug use.

[0189] With regard to infection risk, data on the example implementation of platform 120 evidences when infection may be brewing. Baseline metrics have been identified and added to the resident’s profiles as described above, to automatically flag when the risk of infection is high. For example, early signs of infection can include one or more of the following active alerts: Low Sleep Score, High Sleeping Heart Rate, High Sleeping Respiratory Rate, Increased Breathing Disturbances, Increased Nighttime Bathroom Visits. In some examples, if one or more of these alerts are active, caregivers may decide to test for an infection earlier than they otherwise would, and (if an infection is detected) begin treatment sooner than they otherwise would and thereby avoid the infectiongetting more serious. Upper and lower limits can be set for any of the large number of data measurements on the disclosed platform. For example, baseline values can be set across an entire organization or group of residents or patients. Alternatively, baseline values can be set automatically based on measured data for each individual or can be set manually for each individual. In some examples, alert types where an individual data point is too high or low is supported. In other examples, combinations of one or more data points being either too high or too low can be supported.

[0190] Systems, apparatuses, and methods described herein may be implemented using digital circuitry, or using one or more computers using well- known computer processors, memory units, storage devices, computer software, and other components. Typically, a computer includes a processor for executing instructions and one or more memories for storing instructions and data. A computer may also include, or be coupled to, one or more mass storage devices, such as one or more magnetic disks, internal hard disks and removable disks, magneto-optical disks, optical disks, etc.

[0191] A high-level block diagram of an exemplary apparatus that may be used to implement systems, apparatus and methods described herein is illustrated in FIG. 21. Apparatus 2100 comprises a processor 2110 operatively coupled to a persistent storage device 2120 and a main memory device 2130. Processor 2110 controls the overall operation of apparatus 2100 by executing computer program instructions that define such operations. The computer program instructions may be stored in persistent storage device 2120, or other computer-readable medium, and loaded into main memory device 2130 when execution of the computer program instructions is desired. Thus, the method steps of FIGS. 3 and 4 can be defined by the computer program instructions stored in main memory device 2130 and / or persistent storage device 2120 and controlled by processor 2110 executing the computer program instructions. For example, the computer program instructions can be implemented as computerexecutable code programmed by one skilled in the art to perform an algorithm defined by the method steps of FIGS. 3 and 4. Accordingly, by executing the computer program instructions, processor 2110 executes an algorithm defined by the method steps of FIGS. 3 and 4. Apparatus 2100 also includes one or more network interfaces 2180 for communicating with other devices via a network. Apparatus 2100 may also include one or more input / output devices 2190 that enable user interaction with apparatus 2100 (e.g., display, keyboard, mouse, speakers, buttons, etc.).

[0192] Processor 2110 may include both general and special purpose microprocessors and may be the sole processor or one of multiple processors of apparatus 2100. Processor 2110 may comprise one or more central processing units (CPUs), and one or more graphics processing units (GPUs), which, for example, may work separately from and / or multi-task with one or more CPUs to accelerate processing, e.g., for various image processing applications described herein. Processor 2110, persistent storage device 2120, and / or main memory device 2130 may include, be supplemented by, or incorporated in, one or more application-specific integrated circuits (ASICs) and / or one or more field programmable gate arrays (FPGAs).

[0193] Persistent storage device 2120 and main memory device 2130 each comprise a tangible non-transitory computer readable storage medium. Persistent storage device 2120, and main memory device 2130, may each include high-speed random access memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), double data rate synchronous dynamic random access memory (DDR RAM), or other random access solid state memory devices, and may include non-volatile memory, such as one or more magnetic disk storage devices such as internal hard disks and removable disks, magneto-optical disk storage devices, optical disk storage devices, flash memory devices, semiconductor memory devices, such as erasable programmable readonly memory (EPROM), electrically erasable programmable read-only memory(EEPROM), compact disc read-only memory (CD-ROM), digital versatile disc read-only memory (DVD-ROM) disks, or other non-volatile solid state storage devices.

[0194] Input / output devices 2190 may include peripherals, such as a printer, scanner, display screen, etc. For example, input / output devices 2190 may include a display device such as a cathode ray tube (CRT), plasma or liquid crystal display (LCD) monitor for displaying information to a user, a keyboard, and a pointing device such as a mouse or a trackball by which the user can provide input to apparatus 2100.

[0195] Any or all of the functions of the systems and apparatuses discussed herein may be performed by processor 2110. Further, apparatus 2100 may utilize one or more neural networks or other deep-learning techniques performed by processor 2110 or other systems or apparatuses discussed herein.

[0196] One skilled in the art will recognize that an implementation of an actual computer or computer system may have other structures and may contain other components as well, and that FIG. 21 is a high-level representation of some of the components of such a computer for illustrative purposes.

[0197] Throughout the specification and claims, the following terms take the meanings explicitly associated herein, unless the context clearly dictates otherwise:

[0198] The phrase “in one embodiment” as used herein does not necessarily refer to the same embodiment, though it may. Thus, as described below, various embodiments of the invention may be readily combined, without departing from the scope or spirit of the invention.

[0199] As used herein, the term “or” is an inclusive “or” operator and is equivalent to the term “and / or,” unless the context clearly dictates otherwise.

[0200] The term “based on” is not exclusive and allows for being based on additional factors not described unless the context clearly dictates otherwise.

[0201] As used herein, and unless the context dictates otherwise, the term “coupled to” is intended to include both direct coupling (in which two elements that are coupled to each other contact each other) and indirect coupling (in which at least one additional element is located between the two elements). Therefore, the terms “coupled to” and “coupled with” are used synonymously. Within the context of a networked environment where two or more components or devices are able to exchange data, the terms “coupled to” and “coupled with” are also used to mean “communicatively coupled with,” possibly via one or more intermediary devices.

[0202] Although some of the various embodiments presented herein constitute a single combination of inventive elements, it should be appreciated that the inventive subject matter is considered to include all possible combinations of the disclosed elements. As such, if one embodiment comprises elements A, B, and C, and another embodiment comprises elements B and D, then the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly discussed herein. Further, the transitional term “comprising” means to have as parts or members, or to be those parts or members. As used herein, the transitional term “comprising” is inclusive or open-ended and does not exclude additional, unrecited elements or method steps.

[0203] Throughout the following disclosure, numerous references may be made regarding servers, services, interfaces, engines, modules, clients, peers, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor (e.g., ASIC, FPGA, DSP, x86, ARM, ColdFire, GPU, multi-core processors, etc.) configured to execute software instructions stored on a computer readable tangible, non-transitory medium(e.g., hard drive, solid state drive, RAM, flash, ROM, etc.). For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions. One should further appreciate the disclosed computer-based algorithms, processes, methods, or other types of instruction sets can be embodied as a computer program product comprising a non- transitory, tangible computer readable medium storing the instructions that cause a processor to execute the disclosed steps. The various servers, systems, databases, or interfaces can exchange data using standardized protocols or algorithms, possibly based on HTTP, HTTPS, AES, public-private key exchanges, web service APIs, or other electronic information exchanging methods. Data exchanges can be conducted over a packet-switched network, a circuit-switched network, the Internet, LAN, WAN, VPN, or other type of network.

[0204] As used in the description herein and throughout the claims that follow, when a system, engine, server, device, module, or other computing element is described as being configured to perform or execute functions on data in a memory, the meaning of “configured to” or “programmed to” is defined as one or more processors or cores of the computing element being programmed by a set of software instructions stored in the memory of the computing element to execute the set of functions on target data or data objects stored in the memory.

[0205] It should be noted that any language directed to a computer should be read to include any suitable combination of computing devices or network platforms, including servers, interfaces, systems, databases, agents, peers, engines, controllers, modules, or other types of computing devices operating individually or collectively. One should appreciate the computing devices comprise a processor configured to execute software instructions stored on a tangible, non- transitory computer readable storage medium (e.g., hard drive, FPGA, PLA, solid state drive, RAM, flash, ROM, etc.). The software instructionsconfigure or program the computing device to provide the roles, responsibilities, or other functionality as discussed below with respect to the disclosed apparatus. Further, the disclosed technologies can be embodied as a computer program product that includes a non-transitory computer readable medium storing the software instructions that causes a processor to execute the disclosed steps associated with implementations of computer-based algorithms, processes, methods, or other instructions. In some embodiments, the various servers, systems, databases, or interfaces exchange data using standardized protocols or algorithms, possibly based on HTTP, HTTPS, AES, public-private key exchanges, web service APIs, known financial transaction protocols, or other electronic information exchanging methods. Data exchanges among devices can be conducted over a packet-switched network, the Internet, LAN, WAN, VPN, or other type of packet switched network; a circuit switched network; cell switched network; or other type of network.

[0206] The foregoing specification is to be understood as being in every respect illustrative and exemplary, but not restrictive, and the scope of the invention disclosed herein is not to be determined from the specification, but rather from the claims as interpreted according to the full breadth permitted by the patent laws. It is to be understood that the embodiments shown and described herein are only illustrative of the principles of the present invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention. Those skilled in the art could implement various other feature combinations without departing from the scope and spirit of the invention.

Claims

CLAIMSWhat is claimed is:

1. A method of generating one or more care alerts for one or more patients, the method comprising: a. receiving real-time or near real-time measurement data from one or more sensors located in a living environment of a first patient of the one or more patients; b. using the real-time or near real-time measurement data from the one or more sensors to generate a status report of the first patient; c. identifying at least one rule pertaining to the first patient from an individual rules engine using the real-time or near real-time measurement data from the one or more sensors of the first patient, wherein the identified rule is applied to generate at least one alert indicator for the first patient, wherein the alert indicator comprises an urgent alert, a caution alert, or a stable alert; d. identifying at least one rule from a population rules engine to apply to the first patient using the real-time or near real-time measurement data from the one or more sensors of the first patient and measurement data from a patient population, wherein the identified rule is applied to generate a health assessment for the first patient; ande. generating a user interface for display on a device of a care provider wherein the user interface displays the real-time or near real-time measurement data, the status report, the alert indicator, and the health assessment of the first patient.

2. The method of claim 1, further comprising: a. receiving real-time or near real-time measurement data from one or more sensors located in a living environment of a second patient of the one or more patients; b. using the real-time or near real-time measurement data from the one or more sensors to generate a status report of the second patient; c. identifying at least one rule from the individual rules engine to the second patient using the real-time or near real-time measurement data from the one or more sensors of the second patient, wherein the identified rule is applied to generate an alert indicator for the second patient; and d. identifying at least one rule from the population rules engine to apply to the second patient using the real-time or near real-time measurement data from the one or more sensors of the second patient and measurement data from the patient population, wherein the identified rule is applied to generate a health assessment for the second patient;wherein the user interface further displays the real-time or near real-time measurement data, the status report, the alert indicator, and the health assessment of the second patient.

3. The method of claim 2, wherein the living environment of at least one of the first patient and the second patient is located in a care facility.

4. The method of claim 1, wherein the living environment of the first patient is located in a private residence.

5. The method of claim 1, wherein the device of the care provider is located at a location remote from the living environment of the first patient.

6. The method of claim 1, wherein the alert indicator comprises at least one of: an in bed alert, an out of bed alert, a door open alert, an appliance on alert, a possible fall alert, a continence alert, a missed medication alert, a late bedtime alert, a late home alert, a patient out of bounds alert, an inactivity alert, a measurement out of bounds alert, a configurable measurement alert, or an appliance off alert.

7. The method of claim 1, further comprising sending a push notification, a text message, a Short Message Service (SMS), or a phone call of the alert indicator to a user device of the care provider.

8. The method of claim 1, wherein the patient population comprises the one or more patients.

9. The method of claim 1, wherein the patient population comprises a longitudinal study of patients.

10. The method of claim 1, further comprising: a. upon generating the urgent alert indicator for the at least one rule for the first patient, generating an urgent care request for the first patient comprising a caregiver qualification, a location, a time duration, and a supply list; b. analyzing one or more caregiver profiles, wherein the caregiver profile comprises a caregiver qualification, a current location, a time remaining on current shift, a supply inventory; and an on-call status; c. identifying a caregiver profile of a care provider having a caregiver qualification, a current location, a time remaining on current shift, and a supply inventory that generates a match with the urgent care request for the first patient; andd. transmitting an instruction alert to the user device of the identified care provider to fulfill the urgent care request of the first patient.

11. The method of claim 10, further comprising: a. identifying a plurality of caregiver profiles, wherein each caregiver profile is associated with a care provider having a caregiver qualification, a current location, a time remaining on current shift, and a supply inventory that generates a match with the urgent care request for the first patient; b. transmitting an instruction alert to the user device of each of the matched care providers to fulfill the urgent care request; and c. upon receiving an acceptance from a matched care provider, sending a notification to the other matched care providers that the instruction alert has been fulfilled.

12. A system for generating one or more care alerts for one or more patients, the system comprising: a. a patient settings database comprising a first plurality of records, wherein each record is associated with a specific patient of the one or more patients, and comprises one or more patient settings; b. a patient measurement database comprising a second plurality of records, wherein each record is associated with a specific patient of theone or more patients, and comprises one or more health care data attributes, wherein at least one health care data attribute comprises real-time or near real-time measurement data received from one or more sensors located in a living environment of a first patient of the one or more patients; c. an individual rules engine connected to the patient settings database and the patient measurement database, wherein the individual rules engine is configured to, for the first patient of the one or more patients: i. receiving one or more patient settings corresponding to the first patient from the patient settings database; and ii. based on the one or more patient settings, identify at least one individual rule to apply to the first patient using measurement data corresponding to the first patient from the patient measurement database, wherein the identified individual rule is applied to generate one or more of a status report and an alert indicator for the first patient, wherein the alert indicator comprises an urgent alert, a caution alert, or a stable alert; d. a population rules engine connected to the patient settings database and the patient measurement database, wherein the population rules engine is configured to, for the first patient of the one or more patients: i. receiving one or more patient settings corresponding to the first patient from the patient settings database; andii. based on the one or more patient settings, identify at least one population rule to apply to the first patient using both (1) measurement data corresponding to the first patient from the patient measurement database, and (2) measurement data from a patient population, wherein the identified population rule is applied to generate a health assessment for the first patient; and iii. a reporting module configured to generate and transmit a user interface for display on a device of a care provider, wherein the user interface displays one or more of: the real-time or near realtime measurement data, the status report, the alert indicator, and the health assessment of the first patient.

13. The system of claim 12, wherein the living environment of at least one of the one or more patients is located in a care facility.

14. The system of claim 12, wherein the living environment of at least one of the one or more patients is located in a private residence.

15. The system of claim 12, wherein the device of the care provider is located at a location remote from the living environment of the first patient.

16. The system of claim 12, wherein the alert indicator comprises at least one of: an in bed alert, an out of bed alert, a door open alert, an appliance on alert, a possible fall alert, a continence alert, a missed medication alert, a late bedtime alert, a late home alert, a patient out of bounds alert, an inactivity alert, a measurement out of bounds alert, a configurable measurement alert, or an appliance off alert.

17. The system of claim 12, further comprising sending a push notification, a text message, a Short Message Service (SMS), or a phone call of the alert indicator to a user device of the care provider.

18. The system of claim 12, wherein the patient population comprises the one or more patients.

19. The system of claim 12, wherein the patient population comprises a longitudinal study of patients.

20. The system of claim 12, wherein the reporting module further performs the following operations: a. upon receiving the urgent alert indicator for the at least one rule for the first patient, generating an urgent care request for the first patientcomprising a caregiver qualification, a location, a time duration, and a supply list; b. analyzing one or more caregiver profiles, wherein the caregiver profile comprises a caregiver qualification, a current location, a time remaining on current shift, a supply inventory, and an on-call status; c. identifying a caregiver profile of a care provider having a caregiver qualification, a current location, a time remaining on current shift, and a supply inventory that generates a match with the urgent care request for the first patient; and d. transmitting an instruction alert to the user device of the identified care provider to fulfill the urgent care request of the first patient.

21. The system of claim 20, wherein the reporting module further performs the following operations: a. identifying a plurality of caregiver profiles, wherein each caregiver profile is associated with a care provider having a caregiver qualification, a current location, a time remaining on current shift, and a supply inventory that generates a match with the urgent care request for the first patient; b. transmitting an instruction alert to the user device of each of the matched care providers to fulfill the urgent care request; andc. upon receiving an acceptance from a matched care provider, sending a notification to the other matched care providers that the instruction alert has been fulfilled.

22. The system of claim 12, further comprising an insights module connected to the settings module, individual rules engine, the population rules engine, and the reporting module, wherein the insights module is configured to modify one or more patient settings, individual rules, population rules, alert indicators, or health assessments of the first patient.

23. The system of claim 22, wherein the insights module generates one or more individual rules, population rules, or patient setting modifications using a machine learning algorithm applied to the measurement data of the one or more patients.

24. A computer program product embedded in a non-transitory computer readable medium comprising one or more instructions executable by one or more computer processors to perform: a. receiving real-time or near real-time measurement data from one or more sensors located in a living environment of a first patient of the one or more patients;b. using the real-time or near real-time measurement data from the one or more sensors to generate a status report of the first patient; c. identifying at least one rule pertaining to the first patient from an individual rules engine using the real-time or near real-time measurement data from the one or more sensors of the first patient, wherein the identified rule is applied to generate at least one alert indicator for the first patient, wherein the alert indicator comprises an urgent alert, a caution alert, or a stable alert; d. identifying at least one rule from a population rules engine to apply to the first patient using the real-time or near real-time measurement data from the one or more sensors of the first patient and measurement data from a patient population, wherein the identified rule is applied to generate a health assessment for the first patient; and e. generating a user interface for display on a device of a care provider wherein the user interface displays the real-time or near real-time measurement data, the status report, the alert indicator, and the health assessment of the first patient.