Context aware remote care alert system for patient population

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 an elderly patient and used to generate a status report for the patient. At least one rule related to the patient is identified from the individual rule engine using the measurement data, wherein the identified rule is applied to generate an alert indicator for the patient. Measurement data from the patient and other measurement data from the patient population are used to identify at least one rule relating to the patient from the population rule engine and generate a health assessment for the patient. A user interface is generated on the care provider device that includes at least one of measurement data, status reports, alarm indicators, and health evaluations of the patient.

Description

Context-aware remote nursing alarm system for patient groups Technical Field

[0001] This disclosure generally relates to integrated hardware and software methods and systems for improving patient productivity, efficiency, and quality of care, including older or disabled individuals residing at home or in residential healthcare facilities, retirement living facilities, assisted living facilities, nursing or long-term care facilities, hospitals, or other clinical or non-clinical settings. More specifically, this disclosure relates to inventive methods and systems for generating context-aware care alerts for patient groups, enabling family members and professional care providers to effectively monitor and care for one or more patients remotely or from multiple locations. Background Technology

[0002] Like children, older adults typically require regular care, especially as life expectancy increases. They also frequently express a desire to grow up in their own homes rather than move to nursing homes, aged care facilities, or communities. However, the demand for aged care exceeds the supply in almost every developed country. Demographical demands in developed countries and the strain on healthcare systems in many nations mean that the demand for aged care will continue to grow. Currently, 500 million people aged 65 and over live in G20 countries. By 2050, this number is projected to exceed one billion. For example, in the UK, 1.5 million older adults have unmet needs for care.

[0003] Despite significant advancements in healthcare technology, aged care remains a considerable challenge. Care providers are often overwhelmed by heavy workloads, inefficient practices, and the need for constant, high-level monitoring, leading to decreased productivity and increased stress levels. Furthermore, the need for continuous monitoring of many elderly patients can result in even greater inefficiencies and gaps in care.

[0004] If the productivity of aged care providers remains constant, more than 60% of care providers will be needed by 2040. Healthcare systems in many industrialized countries, as well as developing countries, are often under pressure to focus solely on acute clinical needs. This could further increase the demand for care services for the elderly, particularly as available capacity in hospitals and skilled care facilities is required to serve the most severely ill patients. Routine face-to-face care for the elderly is labor-intensive, inefficient, and expensive. On the other hand, care providers are often overworked and underpaid, leading to a crisis in the care workforce across developed countries. In the UK, the annual turnover rate for care providers is 38%.

[0005] Technology-enabled care (TEC) is an approach being explored to at least partially address unmet needs in aged care. However, many current TEC products are often complex to install but offer only limited point solutions for a specific aspect of aged care (e.g., a call alarm system for an elderly person to summon help after a fall). TEC products typically offer a poor user experience and poor value for money. TEC products also often enter the market quickly and disappear just as quickly, making it difficult for users of such care products to find support and repairs. Finally, TEC products can be cumbersome to use and may be unappealing and unpleasant for the elderly who use these devices.

[0006] A recent study by the Cambridge Institute of Public Health concluded that older adults who are unable to get up after a fall often end up lying on the floor for extended periods, despite the presence of call alarms. In 36 out of 37 cases of “long lies” (97%), the individuals who fell alone did not use their alarms to seek help. Prolonged lying on the floor was also strongly associated with serious injury, hospitalization, and subsequent long-term care.

[0007] More care providers are not a solution either, as, as mentioned above, elderly care is too labor-intensive, expensive, and inefficient. Care providers often have to deal with limited and / or incomplete information (often provided by the patient alone or by other care providers, without access to the patient's medical history or other detailed information). Care providers typically provide care to their elderly and / or disabled clients on fixed and / or limited schedules and cannot have a comprehensive understanding of their patients' daily activities and health conditions. This results in care providers, family members and loved ones, medical professionals, and others involved in elderly care each having different and incomplete information. As a result, problems are often missed until the situation reaches a crisis or emergency stage, at which point a care provider is called. Alternative solutions to these problems are needed. Summary of the Invention

[0008] The systems and methods disclosed herein provide a comprehensive solution that simplifies caregiving tasks, integrates information from various sources, automates alerts and instructions, optimizes care provider activities, and enhances care provider collaboration, ultimately aiming to improve the quality of care by increasing care provider productivity in advanced and other care settings. They leverage sensor technologies, software applications, cloud-based platforms, and data analytics tools to equip care providers with relevant information, insights, and instructions to deliver effective, personalized care. This comprehensive approach emphasizes improving care outcomes and enhancing care provider well-being by reducing workload and stress. In some embodiments, the systems and methods described herein can be personalized and tailored to the needs of specific individuals and / or care providers over time and in changing circumstances. While the systems and methods described herein are generally described in conjunction with older patients (i.e., “elderly people”), they can be used with any individual (i.e., patient) regardless of age. The systems and methods described herein are intended for healthcare or clinical settings but can also be applied to home or other care settings where care providers monitor the health, well-being, and / or safety of patients, older people, and other individuals receiving care.

[0009] Embodiments of the systems and methods disclosed herein include a patient data analytics platform utilized by care providers, interconnected with a network of devices, including but not limited to sensors, machines, measuring devices, software applications, data sources, and other entities. Networked devices are strategically located in the living environment of the elderly person, on the elderly person, or used by the care provider, and communicate data with the cloud-based patient data analytics platform. This platform acts as a comprehensive repository, collecting, processing, and analyzing data to generate insights, alerts, recommendations, and messages for care providers, the elderly person, family members, clinicians, and other stakeholders. Furthermore, it enables device operation to respond to the specific needs of the individual being cared for, as well as the requests of care coordinators and care providers. For example, the patient data analytics platform may provide information to some devices enabling them to operate in response to the specific needs of the person being cared for or the specific requests of the care coordinator or care provider. Machine learning algorithms described herein can take input data collected from networked devices and provide insights and recommendations to care providers to improve the quality of care. Additionally, the patient data analytics platform includes graphical user interfaces (GUIs) for care providers, which present information in an easily understandable format.

[0010] In one embodiment, a method and system for generating one or more 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 the living environment of a first patient among 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 for the first patient. Using the real-time or near-real-time measurement data from the one or more sensors of the first patient, at least one rule related to the first patient is identified from an individual rule engine, wherein the identified rule is applied to generate an alert indicator for 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 group, at least one rule from a group rule engine is identified to be applied to the first patient, 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 care provider's device, wherein the user interface displays one or more of the first patient's real-time or near-real-time measurement data, status report, alert indicator, and health assessment.

[0011] In some implementations, methods for improving the productivity of care providers in advanced care are disclosed. Such methods include the automated monitoring of activities and other information about patients and care providers using fixed sensors, wearable devices, communication devices, and other hardware and software. These methods also include analyzing the collected data to identify areas for efficiency and effectiveness improvement, and monitoring compliance with policies, procedures, directives, and regulations. Additionally, real-time or near-real-time feedback, insights, and directives are provided to care providers and their managers to (1) improve the productivity, effectiveness, and efficiency of care providers, (2) improve care provider compliance with policies and processes, and (3) prioritize care provider actions and interventions based on specific policies, procedures, directives, and regulations applicable to care providers and patients.

[0012] Various objects, features, aspects and advantages of the subject matter of the invention will become more apparent from the following description and accompanying drawings, in which the same numerals denote the same parts. Attached Figure Description

[0013] Figure 1 illustrates an overview of a cloud-based remote healthcare alert system according to some embodiments.

[0014] Figures 2 and 2A illustrate several exemplary graphical user interfaces (GUIs) for care providers, based on examples.

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

[0016] Figure 4 illustrates a method for assigning care providers to respond to a patient’s emergency care alert, according to some embodiments.

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

[0018] Figure 6 shows the GUI of the first dashboard state of an individual patient according to some embodiments.

[0019] Figure 7 shows a GUI of the second dashboard state of an individual patient according to some embodiments.

[0020] Figure 8 illustrates the GUI of the third dashboard state of an individual patient according to some embodiments.

[0021] Figure 9 illustrates the graphical user interface (GUI) of an initial daily summary screen according to some embodiments.

[0022] Figure 10 illustrates a GUI that displays a first transition screen showing a first alarm according to some embodiments.

[0023] Figure 11 illustrates a GUI of a second transition screen displaying a second alarm according to some embodiments.

[0024] Figure 12 illustrates a GUI of a third transition screen displaying a third alarm, according to some embodiments.

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

[0026] Figure 14 shows a GUI of an initial analysis screen that displays the analysis in a colored graphical form according to some embodiments.

[0027] Figure 15 illustrates a GUI of a first transition screen that displays the analysis in a colored graphical form according to some embodiments.

[0028] Figure 16 illustrates the GUI of a second transition screen according to some embodiments, which shows the analysis and filter selection by daily count of nighttime toilet visits in a colored graphical form.

[0029] Figure 17 illustrates the GUI of a third transition screen according to some embodiments, which shows the analysis and filter selection by daily count of nighttime toilet visits in a colored graphical form.

[0030] Figure 18 illustrates the GUI of a fourth transition screen according to some embodiments, which shows the analysis and filter selection for the selected attribute in a colored graphical form.

[0031] Figure 19 shows the GUI of a fifth transition screen according to some embodiments, which illustrates the analysis and filter selection for the selected attribute in a colored graphical form, with the cursor highlighting the daily count of nighttime toilet visits for one night.

[0032] Figure 20 illustrates the GUI of a sixth transition screen according to some embodiments, which shows the analysis and filter selection to attributes with only alarms in a colored graphical form.

[0033] Figure 21 illustrates a block diagram of a computer system that can be used to implement one or more aspects of various embodiments.

[0034] Although the invention has been described with reference to the accompanying drawings, the drawings are intended to be illustrative, and other embodiments are consistent with the spirit of the invention and are within the scope of the invention. Detailed Implementation

[0035] Various embodiments will now be described more fully below with reference to the accompanying drawings, which form part of this document and illustrate specific examples of practical embodiments by way of illustration. However, this specification may 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 embody a method or system. Therefore, any of the various embodiments described herein may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Therefore, the following description should not be considered limiting.

[0036] To provide a more thorough understanding of the invention, the following description sets forth specific details, such as specific configurations, parameters, colors and / or patterns, specific examples, etc., used in the exemplary user interface depicted in black and white drawings. However, it should be understood that this description is not intended to limit the scope of the invention, but rather to provide a better description of exemplary embodiments.

[0037] According to various embodiments, this disclosure may relate to systems and methods for generating one or more care alerts for one or more patients.

[0038] It should be understood that the disclosed technology provides a number of 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] It should be understood that the disclosed technology offers numerous advantageous technical effects, including an interactive computer interface method for visually viewing, identifying, and responding to care alerts from elderly, disabled, and other patients requiring remote monitoring and / or medical assistance. The disclosed technology has been designed to support the review, identification, monitoring, and routing of care alerts at a scale and speed unattainable using human intervention.

[0040] It should also be understood that the following instructions are not intended as a broad overview, and therefore, concepts may be simplified for clarity and brevity.

[0041] The disclosed system examples provide a user-friendly interface not only for care providers but also for family members and patients or residents themselves, allowing for active participation in care monitoring and decision-making. The disclosed system examples provide real-time updates on health and behavior, enabling families to receive notifications about their resident loved ones and / or remotely check care progress. In some aspects of the disclosed platform, user interfaces can be configured for both care providers and family members, providing monitoring of real-time health metrics and behavioral data of the resident via one or more connected sensors. Examples of such engaging platforms may include interfaces such as dashboards or mobile applications that provide updates on the resident or patient, enabling authorized family members to remotely participate in and monitor health, behavior, or life conditions.

[0042] Examples of the disclosed systems may also leverage artificial intelligence, including machine learning algorithms and predictive analytics, to analyze historical patient data and behavior and predict potential health events or risks, such as falls, infections, or behavioral changes. In some aspects, the disclosed systems are designed to provide early alerts to care providers and family members when a problem first arises, enabling timely intervention before the condition or problem worsens or becomes critical. Examples of the disclosed systems are configured to use machine learning algorithms to analyze historical and real-time data from one or more sensors, where the system predicts potential health risks, such as falls or dehydration, and generates alerts based on deviations from the monitored individual's established behavioral or physiological baseline. Such alerts predict potential health risks rather than simply focusing on biometrics or other data obtained using traditional sensor-based methods.

[0043] In addition to monitoring residents' physical health, the disclosed examples of systems can identify and track behavioral changes, such as abnormal and / or prolonged 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 care providers and family members, facilitating early intervention for residents before problems arise. Problems may emerge and / or worsen. Therefore, some examples of the disclosed systems monitor changes in the behavior and mood of patients or residents. These example systems use one or more sensors to track physical activity, sleep patterns, or environmental interactions, where deviations from the patient's or resident's normal behavioral patterns indicate potential emotional or psychological distress and can trigger automated alerts to care providers and / or family members to facilitate early intervention.

[0044] In some examples, the disclosed systems enable customized or personalized care plans for each of one or more patients or residents based on ongoing patient or resident data, such as the patient's or resident's unique needs, preferences, or medical condition. Over time, examples of the disclosed systems dynamically adjust the care plans for each of one or more patients or residents based on ongoing health data, thereby optimizing care delivery for each individual resident or patient. Thus, examples of the disclosed systems are configured to generate and dynamically update personalized care plans for each of one or more individual residents or patients, where personalized care plans are adjusted in real time based on data from one or more sensors or user input. Data from one or more sensors and one or more user inputs can be analyzed to help ensure that personalized and responsive care is provided tailored to the specific health conditions and preferences of the resident or patient. In some examples, data from one or more sensors and one or more user inputs can be analyzed using one or more machine learning models or algorithms to further optimize the personalized and responsive care provided to residents or patients.

[0045] Examples of the disclosed systems utilize real-time data analytics tools to further improve the operational efficiency and financial performance of care facilities. These tools optimize caregiver task prioritization, reduce admissions, and provide operational insights to help care facilities reduce costs and improve service quality. For instance, the disclosed systems can improve the operational efficiency of senior living communities by automating routine care tasks, thereby enabling more effective prioritization of care provider activities and reducing admissions. In some examples, the real-time analytics of the disclosed systems help care facility operators optimize staffing, streamline operations, and demonstrate improved health outcomes, thereby increasing the revenue potential of care facilities implementing all aspects of the disclosed systems.

[0046] Figure 1 illustrates an overview of a cloud-based remote healthcare alert system 100 according to some embodiments. In some embodiments, system 100 may include a cloud-based platform for collecting and analyzing data related to the health, well-being, and safety of patients, including the elderly and disabled. In some examples, patient care alerts, patient status information, and patient health insights may be delivered to caregivers and care providers via a cloud / network 118 from system platform 120 using a graphical user interface (GUI) delivered to devices 110 and 114 via a mobile application, which may include mobile phones, tablets, or similar devices; and / or via a desktop application on a desktop or laptop computer 112. Alternatively, patient care alerts, patient status information, and patient health insights may be delivered to caregivers and care providers via text messaging (e.g., SMS, email, XML, mobile app notifications, or other methods).

[0047] As discussed herein, caregivers and care providers will be able to utilize a GUI to view and explore relationships between patients' sleep, toileting, blood glucose levels, medication use, and other health and activity data, which can be stored in a patient database 125. Database 125 may include a broad and comprehensive collection of measurements and data, enabling algorithms that rely on combinations of different data (e.g., sleep quality, toileting, and medication adherence) to be applied and utilized on an individual patient basis, as well as for longitudinal (time-based) and longitudinal (time-based) data analysis across one or more populations. Summary reports containing measurement trends and data specific to individual patients can also be generated via reporting module 126. In some embodiments, care provider database 123 may include information about care providers, including but not limited to: care provider name, care provider skills, assigned patients (e.g., VIPs or seniors), rate / hr, current status (e.g., on / off duty, current task, time to completion of current task, time to off / on duty, current location, currently available supplies).

[0048] In some embodiments, third-party clients may also be able to utilize patient data from the patient database 125 within the system platform 120 via an application programming interface (API), where appropriate and permissible, including patient data (e.g., VIP (Vulnerable Individual) API 124). In some embodiments, the API may be Open API 3.0 (or higher) compatible. Third-party clients may include an alarm response center system 131 (e.g., an exemplary third-party client alarm response system 131 may include a system for assisted living facilities, such as Legrand / Jontek), an electronic health record system 133 (e.g., an exemplary third-party client EHR system 133 may include a system produced by Patient Best Known (PKB)), and a care management system 135 (e.g., an exemplary client caregiver application 135 may include a software system produced by an access group).

[0049] In some embodiments, the individual rule engine 150 monitors the database 125 at rule intervals or at one or more designated times of day. The monitoring intervals can be stored in dedicated storage, accessible to the individual rule engine 150 for patient (e.g., VIP) settings 127. The monitoring intervals may vary per patient or from a specific data source configured for a particular patient situation. Depending on the monitoring intervals, one or more insights can be generated and stored in the patient (VIP) insight database 128. The patient insight database 128 may include notifications, alerts, and warnings. The patient insight database 128 may also include anomalies, rule violations (e.g., rule violations in the patient insight database 128), etc., and suggested investigations. Such insights can also be generated using results from the machine learning engine 129, and trained on data from the patient database 125 (or data from an external database, such as data contained in the EHR system 133) based on the machine learning implementation created herein.

[0050] In some embodiments, some of the generated insights may include simple notifications such as “low hydration.” Low hydration can be detected by sensors in the patient’s drinking water bottle, cup, or water dispenser, for example, indicating that the amount of water consumed or dispensed is below average, and may trigger a notification to the patient to drink more water. In some embodiments, other generated insights may utilize more complex logic that can record anomalies, rule violations, or suggested investigations. For example, an insight notification may include an anomaly or violation such as: “The patient (VIP) was not in bed last night and went to the bathroom, but has not returned to bed for more than 30 minutes since they went to the bathroom.” For example, such insights may generate suggested investigations, such as issuing an emergency alert notification to the care provider to check on the patient. Thus, insights that include notifications, alerts, and warnings may include a single piece of information (e.g., the VIP was not in bed last night), a value that has fallen outside the permissible range (e.g., a sleep score that is too low), a combination of multiple pieces of information (e.g., a combination of high sleep heart rate, high nighttime bathroom use, and poor sleep quality that indicates the need to check for infection), a rate of change of a value (e.g., hydration decreasing by more than 1% per day), or an instruction to do something (e.g., change the incontinence pad).

[0051] The group rule engine 152 applies general rules or algorithms across one or more patient groups, collecting measurement data for said one or more patient groups and storing it in the patient database 125. These rules can be derived from published clinical and academic research. New algorithms or rules can be added when new research is published. An example of such an algorithm is based on the following study published by the University of Surrey, UK, which detects the likelihood of an increased urinary tract infection (UTI) based on trends in sleep quality and urination. Other rules can be generated based on longitudinal trends and changes in behavior over time, and can also be derived using machine learning techniques applied to health, sleep, activity, safety, medication, nutrition, and other data obtained from one or more patient groups stored in the patient database 125. In some embodiments, the patient database 125 and the care provider database 123 can be configured for individual, longitudinal (time-based), and group-wide analyses.

[0052] In some embodiments, sensors and devices located on the patient or in the patient's bedroom or residence can be connected via cloud 118 to transfer patient data to a patient database 125 within system platform 120, where appropriate and permissible, via an application programming interface (API) (e.g., data API 122). In some embodiments, data API 122 will enable multiple integration channels to bring patient data to platform 120. In some examples, API 122 may be open API 3.0 compliant and support third-party integration services, making it easy to add new devices and data sources. In some embodiments, patient database 125 may include patient biographical, biometric, or health-related data, including but not limited to: name, age, gender; address / facilities / rooms; health status; medications, a list of required care providers and their timing and frequency; patient personal preferences (e.g., do not enter the room except in emergencies); patient-specific needs (e.g., starting a new medication that may make the patient unstable at night).

[0053] In some embodiments, sensors and devices may include, but are not limited to, devices that have been proven to be scalable, safe, and reliable, and may be supported by secure, certified, and high-performance platforms and proprietary, open, and / or public APIs. In some embodiments, such sensors and devices may include connected gas, smoke, carbon monoxide, and heat alarms 147 (e.g., connected via a third-party API, such as FireAngel); connected sleeping mats, scales, blood pressure monitors, thermometers, heart rate monitors, and pulse oximeters 145 (e.g., connected via a third-party API such as Wiings); connected activity, presence, power, 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, the Ruby on Rails server-side web application framework can be used to build platform 120, although other similar web application frameworks may be used. In some embodiments, the patient database 125 can be built using the PostgreSQL relational database management system, and the data can be stored and manipulated using flat JSONB (JavaScript Object Representation Binary) data types or data structures. In some embodiments, the front end of platform 120 can be constructed using JavaScript and HTML (Hypertext Markup Language) programming languages, as well as the Haml (HTML Abstract Markup Language) template engine for HTML. In some embodiments, Hotwire (which stands for Online HTML) provides client-side interactivity, using Turbo to manage HTML requests and direct responses to the server.

[0055] In some embodiments, server-side memory caching can be implemented by three Memcached instances and one Redis (remote dictionary server) data structure server instance for background job caching. Memcached is a free, open-source, high-performance, distributed memory object caching system for dynamic web applications.

[0056] Figures 2 and 2A illustrate several exemplary graphical user interfaces (GUIs) for care providers, according to an example. Desktop application 210 (in Figure 2) runs on desktop computer 112, and mobile applications 220 and 230 (in Figure 2A) run on mobile devices (e.g., tablets and / or smartphones) 110 and / or 114, respectively (where computing devices 110, 112, 113, 114). In some embodiments, the React native open-source UI (user interface) software framework may be used to develop operating systems (e.g., one or more of operating systems 112 and 114 run on, for example, iOS, Windows, and / or Android operating systems). In some embodiments, OneSignal and Postmark or similar services may be used to handle mobile push notifications and email notifications.

[0057] In some embodiments, system 100 may include real-time unification of data from multiple disparate sources, each with unique requirements regarding API configuration, security profiles, content negotiation, data format and schema, minimum latency, and acceptable return codes. Data cycles may be triggered by user events. In some embodiments, data is fed into a queue-triggered cloud-based workflow using a continuously available, ultra-low-latency webhook or HTTP-POST endpoint that delivers data at least once. The workflow retrieves data from the source API, identifies the user, reformatts it to a schema for patient database 125, and then relays 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 relating to individual biometric readings, etc. Sensitive health-related data may require high-specification transport security and encryption at rest. In some embodiments, each branch of the data cycle may leverage secure authentication based on individual OAuth / OIDC, with complex requirements for continuous authorization to each API in the form of a set of linked, securely stored OAuth refresh tokens, each OAuth refresh token itself being updated in each data cycle.

[0058] In some embodiments, low public endpoint latency (e.g., a maximum of 2 seconds round trip), low operational end-to-end latency (e.g., approximately 800-1600 ms from data ingestion at, for example, sensors 141, 143, 145, and 147 to receiving a POST request at the web server on platform 120), and low processing cost are desirable. In particular, low processing cost may be important for non-state-changing events and should be identified and discarded with minimal cost and resource consumption.

[0059] Figure 3 illustrates a method 300 for generating one or more care alerts for a patient for the purpose of monitoring and improving advanced 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 the patient's living environment. Sensors and devices (such as those described with respect to connection devices 141, 143, 145, and 147 of Figure 1) can be strategically placed around the elderly person's home and elsewhere to collect information. In operation 340, a patient status report is generated using the real-time or near-real-time measurement data from one or more sensors. Such a status report may include data as shown in the exemplary GUIs 210, 220, and 230 of Figure 1. 2. For example, data related to sleep duration, sleep onset time, sleep heart rate, respiratory rate, bedtime, wake-up time, and wake-up time can be measured via operation of a connected sleep pad or a connected CPAP (continuous positive airway pressure) machine. For example, a door sensor or motion sensor can measure the number and duration of nighttime bathroom visits or time spent away from home.

[0060] In Operation 360, in some embodiments, real-time or near-real-time measurement data is used to identify at least one patient-related rule from an individual rule engine (e.g., individual rule engine 150) to generate an emergency, alert, or stabilization alarm. In some examples, an alarm may include a message or data point, a value that has fallen outside the permissible range (e.g., a measurement out-of-bounds alarm), a combination of two or more messages, a rate of change of a value, or an instruction to do something. For example, an alarm may include one or more of the following: in-bed alarm, out-of-bed alarm, door open alarm, appliance open alarm, possible fall alarm, incontinence alarm, missed medication alarm, late-night alarm, after-home alarm, patient alarm, sleep alarm, out-of-bounds alarm, inactivity alarm, measurement out-of-bounds alarm, or configurable measurement alarm. In some embodiments, a patient out-of-bounds alarm may occur if the patient is in an area outside their normal position. In some embodiments, an inactivity alarm may be generated when a combination of circumstances indicating that a VIP may need assistance occurs, such as it is nighttime and the patient is at home, has gotten up, has not yet returned to bed, and has not done anything within 30 minutes. In some embodiments, an out-of-bounds alarm is generated when a measurement is too high, too low, or changes too rapidly. For example, an alarm may be generated for measurements such as skin temperature, body temperature, heart rate, wake-up count, toilet visit count, wake-up count, blood pressure, sleep score, steps, respiratory rate, pain score, or other similar measurements. In some embodiments, an alarm may be generated based on a combination of measurement data points configurable by the user (e.g., a care provider), such as an elevated sleep heart rate plus increased nighttime toilet visits plus decreased sleep quality, or any similar alarms that may indicate a need for the care provider to conduct an investigation.

[0061] Other examples of alarms include the following security and mobility alarms, which can be detected via one or more smart devices, such as sleeping mats that do not pose a tripping hazard, motion sensors, door sensors, toilet sensors, and security floor tracking mats.

[0062] -Nighttime bed-out alarm: The patient gets out of bed at night and does not return within the set time frame.

[0063] -Potential fall alert: An abnormal movement pattern or prolonged inactivity that suggests a possible fall is detected.

[0064] - Increased risk of falls alert: Multiple indicators detected through gait analysis, such as reduced activity, slower movement, or instability.

[0065] - No movement detected for an extended period: Inactivity exceeding a safe threshold is detected (e.g., no movement is detected within 6 hours during the day).

[0066] - Frequent urination alerts: Patients have an unusually high number of urinations at night, which may indicate a urinary tract infection (UTI) or other problems.

[0067] - Loitering alert: The patient leaves the designated safe area or residence, which is especially important for individuals with dementia.

[0068] - No assistive device used: Detection indicates that a patient is walking without their prescribed assistive device (e.g., walker, cane), increasing the risk of falls. This detection can be performed using a motion sensor with an accelerometer, which can be attached to the patient and / or the prescribed assistive device.

[0069] Examples of medication and health monitoring alerts include the following, which in some embodiments can be detected by smart pillboxes or similar devices, for example:

[0070] -Missed medication alert: The patient did not take the medication at the scheduled time (tracked via smart pillbox or similar device).

[0071] - Delayed medication alert: Medication was administered, but later than the prescribed window.

[0072] - Dosing the same medication twice alert: If a patient takes the same medication more than once in a short period of time, it may indicate an overdose.

[0073] - New symptom report alert: Patients report new symptoms (e.g., pain, dizziness, or nausea) via self-assessment tools available on some embodiments of Platform 120. For example, the self-assessment tool may include a GUI available on a tablet, smartphone, smartwatch, or laptop computer, where the patient or resident physician can press a button to indicate high-level or sudden onset of pain, dizziness, or nausea.

[0074] - Low adherence to medication regimen alerts: Over time, if adherence to the medication schedule falls below a certain threshold (e.g., if the smart pillbox reports a threshold number of missed medications, an alert may be triggered to the patient).

[0075] - Treatment plan non-compliance alert: If a patient does not follow the prescribed treatment plan (e.g., does not use prescribed equipment such as a CPAP machine).

[0076] - Abnormal heart rate alert detected: Heart rate readings from one or more wearable devices fall outside the preset range.

[0077] - Abnormal blood pressure alert detected: Blood pressure readings indicate high or low blood pressure.

[0078] - High Pain Score Report Alert: Patients report high levels of pain using the self-assessment tool on the Amba platform as described above.

[0079] Examples of sleep and breathing monitoring alerts used in some embodiments of the disclosed platform include the following:

[0080] - Poor sleep quality alert: A patient's sleep data (e.g., restless movement, frequent awakenings) indicates poor sleep quality and can be tracked by one or more detection devices (e.g., motion sensors) and smart devices (e.g., sleep mats).

[0081] - Sleep apnea or irregular breathing is detected: via sleep monitor or CPAP machine.

[0082] - Abnormal breathing pattern alert: Breathing rate exceeds the expected range during sleep or rest.

[0083] - Daytime excessive sleepiness alert: Data from wearable devices or motion sensors shows that the patient is napping or less active during the day.

[0084] - Snoring or increased noise detection alarm: Increased snoring or noisy breathing can be detected via a noise detector, indicating potential breathing problems.

[0085] - Low oxygen saturation alarm: The 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 alarm: A smart thermostat or thermometer can be used to sound an alarm when it detects that the room temperature is too high, which can be dangerous for elderly patients.

[0088] - Low temperature alarm: A smart thermostat or thermometer can be used to issue an alarm when the room temperature is too low, indicating the risk of hypothermia or an uncomfortable environment.

[0089] - High humidity alarm: Detects excessively high humidity levels in the room, which can increase breathing problems.

[0090] - Smoke / Fire / CO2 Detection Alarm: Smart smoke, fire, or carbon monoxide detectors report hazardous events.

[0091] - Nighttime light alert: A patient leaving a light on at night may indicate confusion or wandering.

[0092] Examples of nutrient and hydration alerts used in embodiments of the disclosed platform include the following:

[0093] -Low fluid intake alert: Based on a smart hydration bottle or fluid intake tracker, the patient is not drinking enough water.

[0094] -Missed Meal Alert: Patients who miss a meal can be detected by connected kitchen sensors or smart appliances.

[0095] -Weight loss detection alert: Significant, unexplained weight loss was detected by the 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 may include those involving motion sensors, connected kitchen sensors, smart appliances, and data tracking such routine daily activities:

[0098] - Abnormal behavior pattern alert: Detects changes in routine activity patterns that may indicate cognitive decline or confusion (e.g., wandering, not following usual routines).

[0099] - Increased confusion alerts: Multiple indicators, such as wandering or failure to complete basic tasks (e.g., dressing, cooking), indicate cognitive decline.

[0100] - Memory loss is detected: It is detected by missing or repeating activities that indicate memory loss (e.g., forgetting to turn off the stove or leaving the refrigerator open).

[0101] - Abnormal sleep / wake cycle alert: Significant deviations from the normal sleep / wake pattern indicate cognitive or mental health problems.

[0102] Examples of social engagement and communication alerts used in embodiments of the disclosed platform may include the following:

[0103] -Low Interaction / Participation Alert: Patients show little or no social interaction or participation within a set time period, which may indicate isolation or depression and can be tracked via motion sensors or wearable devices.

[0104] - Alert for missed social events: Patients missing scheduled social or recreational activities can be an early sign of social withdrawal or declining health, and can be tracked through, for example, app-based checks.

[0105] - Registration failure alert: The patient has not completed the scheduled registration via health call or app-based check.

[0106] In some examples, hygiene and personal care alerts used in embodiments of the disclosed platform may include the following:

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

[0108] - Unusual bathroom usage alerts: Significant changes in bathroom habits detected by bathroom or toilet sensors can indicate events or patterns of increased or decreased use, which may suggest digestive or urinary problems.

[0109] - Incontinence pad replacement alarm: Use a sensor or smart incontinence product that alerts you when a replacement is needed.

[0110] In some embodiments of the disclosed platform, examples of motion and activity-based alerts may 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 below a set threshold, potentially indicating drowsiness or health problems.

[0112] - Overactivity alert: Activity trackers and other wearable devices can be used to detect abnormally high activity levels that could lead to fatigue or injury (e.g., moving too much after surgery or injury).

[0113] - Sedentary alert: Activity trackers and other wearable devices can also be used to detect prolonged periods of inactivity that may increase health risks, such as blood clots, obesity, or muscle atrophy.

[0114] - Abnormal gait or walking pattern alert: Detected irregular walking patterns can indicate weakness, instability, or the onset of health problems such as arthritis. These irregular walking patterns can be detected by an accelerometer worn by the patient or attached to a lightweight wristband.

[0115] Examples of publicly disclosed platforms may also include general health deterioration alerts, which may 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, diet, 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 inability to perform daily activities indicates a serious health problem.

[0118] In some implementations, alert types can be explicitly created by a person on platform 120, or created and made available to users using artificial intelligence (AI) and / or machine learning (ML) capabilities within platform 120. In some embodiments, system 100 may be configured such that each VIP / patient's combination or isolated combination of symptoms and indications may indicate a potential problem or risk. Over time, system 100 may also identify relevant problems actually occurring to VIPs and derive possible relationships with symptoms and indications that may have occurred hours, days, or months prior. Such information can be used to create alerts for caregivers and other care providers, enabling them to immediately investigate further or provide insights for later investigation and / or consideration.

[0119] Information and related alerts can be presented in real time on desktop, mobile application, and tablet user interfaces as described above, using push notifications, icons that change color or shape on the patient profile screen, sounds emitted on the GUI, VIPs order that changes on the GUI based on changing urgency (top or bottom), and / or as a summary report of all alerts, or an exported report of alerts. On other interfaces, information and related alerts can be presented, for example, as push notifications on mobile devices, robocalls, SMS, via existing alert systems such as nurse call systems, via speakers or smart speakers, or via API to the Alert Receiving Center (ARC), or via email or other communications such as:

[0120] Health alert: Check for infection – Jackie is going to the bathroom more often at night, has poor sleep quality, and has a higher than usual sleep heart rate.

[0121] There are several different ways to apply machine learning to create insights and alerts. For example, in some embodiments, a recurrent neural network can be used to perform time-series analysis, employing Long Short-Term Memory (LSTM) units for sleep pattern detection to monitor and assess a person's sleep quality over time. LSTM networks are well-suited for time-series data such as sleep patterns. By comparing continuous data of an older person's nighttime rest, such as sleep cycle detection, snoring, breathing disturbances, and heart rate data obtained from a sleep tracking pad—for example, an LSTM can be used to identify deviations from a person's bed or wearable device (e.g., an accelerometer or activity recorder) from typical sleep patterns. In some embodiments, if an LSTM network trained by and implemented in system 100 detects significant irregularities, such as prolonged restlessness, the system generates an "alert" or "insight" indicating a potential sleep disorder or health problem and sends these alerts or insights to the care provider's user interface.

[0122] In other embodiments, anomaly detection using a class of Support Vector Machines (SVMs) can monitor the activity of older adults. SVMs, particularly a class of SVMs, can be used to detect anomalous activity or inactivity, such as prolonged periods without getting out of bed, or unusually slow movement or decreased gait, which may indicate potential falls or other health-related problems. In some embodiments, the class of SVM algorithms are primarily trained on data including “normal data,” generated based on an individual’s (e.g., older adult’s) normal daily activities and movements, on an individual basis as well as on a group or cluster of older adults. Detected anomalies can generate notifications to care providers in system 100 in the form of “alerts” for potentially harmful situations requiring immediate action (such as potential falls), or “insights” for less urgent but still unusual patterns of activity or inactivity that should be flagged to care providers for further investigation.

[0123] In some other implementations, random forest classifiers are used to predict healthcare-related behaviors of older adults, such as medication adherence. For example, random forest classification can be used to predict whether an older adult is likely to miss their medication based on past behavior, environmental factors, or health status. In such embodiments, the random forest classifier utilizes multiple decision trees during training and outputs the class selected by the majority of trees for classification. By inputting data on when and how often an older adult takes their medication, the random forest classifier can predict with a certain probability whether a particular older adult is likely to miss a dose. An “alert” or “insight” can then be generated in the event of anticipated dose misses, allowing care providers to proactively intervene. In all cases, the model can be retrained periodically or continuously using fresh patient data to ensure accuracy and relevance, especially as older adults’ habits and health status change over time.

[0124] In some embodiments, instances of an alarm may have settings or values ​​that can be set for: the entire patient population; a group of people in a care facility, department, floor, or building; a group of people with similar characteristics, behaviors, conditions, and / or histories; and an individual. As described below, alarms can be set manually, automatically, or using AI and / or ML as previously described. Additionally, in some embodiments, settings for individuals or groups may be changed continuously, periodically, and / or automatically by or via the platform based on changes in an individual's behavior or habits; information provided about an individual's condition, preferences, or needs; or information about other people derived from within or outside the platform 120.

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

[0126] In Operation 380, using real-time measurement data from the patient and measurement data from the patient population, at least one rule is identified from the population rule engine to be applied to the patient, thereby generating a health assessment (or, in some examples, an alert) for one or more patients.

[0127] In operation 390, in some embodiments a user interface is generated for displaying a care provider device that displays one or more of the patient’s measurement data, status reports, alarm indicators, or patient health assessments.

[0128] In another example, a semi-automatic alarm can be created when a platform user (e.g., a caregiver or care provider) tells Platform120, such as, "People over 80 years of age who get out of bed more than three times a night without using a walker are four times more likely to fall." The system then creates a new alert, such as, "Alert the care provider if the patient gets out of bed at night and does not move their walker within X seconds." In this example, settings could include the patient's age, the number of times the patient gets out of bed, and the amount of time prior to creating the alert.

[0129] In some embodiments, the automatic alarm is a new alarm type created by platform 120 based on data it has already analyzed, for example, using machine learning engine 129. The analyzed data may be collected by sensors connected to the patient or the patient's home, or the analyzed data may come from other sources. For example, platform 120, via machine learning engine 129, can identify a possible relationship between a patient with a urinary tract infection (UTI) and an earlier increase in nighttime urination and sleep heart rate. Therefore, platform 120 creates a new alarm type that alerts to a possible UTI upon noticing an increase in urination frequency and sleep heart rate.

[0130] Figure 4 illustrates a method 400 for assigning care providers to respond to emergency care alerts from patients, according to some embodiments. Such a method enables system 100 to help monitor and improve advanced care. Machine learning algorithms, as described above, can also be used in some paradigms to provide insights and recommendations to care providers. Care provider productivity can also be improved, as care providers can provide more effective care to older adults. For example, information about patients' needs and preferences can be stored in database 125. Similarly, information about the skills and qualifications of care providers currently on shift can be stored in database 125 or another database accessible to platform 120. In some examples, current information about shift care providers can also be stored. For example, the care provider's current location and information about the care provider's length and importance. Their currently ongoing tasks can be provided. Information about the current needs of other patients assigned to shift care providers, as well as the potential needs of other patients in the coming hours, can also be stored in a database accessible to platform 120.

[0131] In operation 420, in some examples, an emergency care request is generated for the patient upon receiving an emergency alert indicator for at least one rule targeting the patient. The emergency care request may include care provider eligibility, location, duration, and a list of supplies. As described above, system 100 can automatically monitor patient activity and other information using fixed sensors, wearable sensors, communication devices, and other hardware and software. Care provider activity and location can also be monitored and / or tracked in a manner comparable to that discussed above. In operation 440, one or more care provider profiles are analyzed. In some embodiments, the care provider profile may include care provider eligibility, current location, remaining time for the current shift, supply inventory, and standby status.

[0132] In operation 460, the provider profile, current location, remaining time of the current shift, and supply inventory of at least one qualified provider are identified, and a match is generated for the patient's urgent care request (or at least the closest match from the currently working provider). In operation 480, an instruction alert is transmitted to the user device of the matched or identified provider, instructing the identified provider to meet the patient's urgent care request and address the patient's care needs. In some examples, the system may wait to see if the task is accepted by the closest matched provider before notifying one or more other providers of the urgent care request. After the task is accepted, platform 120 may collect information on whether and when the instructed care intervention was performed to address the urgent care request and by whom.

[0133] For example, in one scenario, a medication sensor (sensor 1) located in the patient's residence can detect that medication has been missed and an incontinence sensor (sensor 2) can detect that an incontinence pad needs to be changed soon. An emergency care alert can be generated for the patient based on the rules described above. In this example, platform 120 will be able to determine which care providers are currently on duty, what qualifications each care provider has, what licenses and knowledge they possess, what supplies they carry, whether they might be needed elsewhere (or soon to be off duty), 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 meet the patient's needs as described above. In one embodiment, the care provider can accept or refuse the request.

[0134] In some embodiments, platform 120 can be used to prioritize and schedule care provider actions. For example, when providing care to older adults in a care facility at night, individual patient preferences, policies, regulatory requirements, and specific needs may come into play. For instance, a patient may have a personal preference that no one enters their room at night except in an emergency. However, care provider facility policies may require a health check for each resident every 3 hours. Regulatory requirements may stipulate that for certain medical conditions or levels of need (e.g., end-of-life care), all government-subsidized care provisions must include hourly (or other periodically scheduled) nightly health checks. Furthermore, specific patient needs can be identified (e.g., a hospitalized patient who has started taking medication that makes them unsteady on their feet at night, thus requiring an hourly nightly health check). Additionally, machine learning / AI components may be present to determine this specific need, which can be implemented as described above. For example, a man over 80 years of age taking a specific medication and having high blood pressure may be known to experience dizziness when starting this specific medication. System 100 can then track this data across patient groups. In this context, the machine learning component implemented as described above in embodiments of the present invention can identify potential problems by tracking data such as the age of people taking the drug, suffering from hypertension, and experiencing dizziness / falls.

[0135] In one example, platform 120 uses real-time information collected by sensors and devices from patients and care providers to assess the aforementioned needs, preferences, and strategies in order to prioritize and / or schedule the actions of care providers, such as care provider 1 should go to room 345 next.

[0136] Platform 120 can also help improve the productivity of care providers in delivering advanced care, particularly in analyzing collected data to improve efficiency and effectiveness, and in monitoring compliance with policies, procedures, rules and regulations.

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

[0138] In addition, Platform 120 can help prioritize care provider actions and interventions based on the specific policies, procedures, instructions, and regulations they are working on.

[0139] In some embodiments, platform 120 may also provide intelligent management and distribution of alerts based on factors such as the care provider and / or the care provider's proximity, shift schedule, qualifications, cost-effectiveness (e.g., the care provider's hourly rate), current workload, and potential urgent care needs elsewhere, thereby effectively allocating care providers' tasks where possible. As an example, a first sensor may detect that a patient has missed medication, and a second sensor may detect that an incontinence pad needs to be changed quickly. Platform 120 identifies one or more of the following information: where the caregiver is, their qualifications, their licenses and knowledge, what supplies they carry, whether they are likely to be needed soon elsewhere (or are off duty), and / or how much they cost. Using such information, platform 120 selects one or more care providers and requests them to address the patient's needs (administering medication, checking the medication dispenser, and changing the incontinence pad). In one embodiment, a care provider may accept or reject a request by: (1) a desktop, mobile application, or tablet user interface; (2) speaking to a smart speaker that sends the request; (3) sending an SMS in response to the request; (4) speaking to a robot call in response to the request; or (5) pressing a button on a telephone handset or mobile phone to respond to a robot call.

[0140] In some embodiments, platform 120 can be used to optimize medication management in patient care, including using devices with integrated technologies to dispense medications to track medication adherence. Notifications and reminders can be provided to care providers and older adults to ensure medication adherence. Finally, medication data can be integrated into platform 120 for comprehensive monitoring and reporting.

[0141] In some embodiments, platform 120 can be used to optimize patient safety. Wearable sensors, presence sensors, GPS trackers, radar-based sensors for detecting persons without behavioral capacity, and / or location sensors can be used to detect and alert care providers to potential safety hazards, such as falls or wandering. For example, real-time notifications and alarms can be generated, allowing care providers to be notified of safety hazards and to intervene in a timely manner. Finally, historical data can also be analyzed to identify patterns and trends in proactive safety measures.

[0142] In some embodiments, platform 120 can be used to improve patient nutrition. Sensors can be used to monitor hydration, eating habits, nutritional levels, etc. Intake can be monitored via sensors in the kitchen and / or wearable sensors and devices. In some embodiments, connected food scales, food purchases, and urine / feces monitoring can also be tracked. Platform 120 can be integrated with a senior living center's food and beverage system to track food consumption in the senior care facility, or data can be obtained from a care management system into which care providers have entered food and beverage intake for VIPs or seniors. Additionally, some embodiments may use sensors to perform urine / feces monitoring, analyzing urine when it enters the toilet and / or analyzing images of feces when it is in the toilet. This data can be combined with other health care data, such as activity, sleep, heart rate, prescription medications, and medication adherence. Nutritional data can be integrated into platform 120 along with other patient data as described above to track and analyze patient eating patterns. Personalized nutritional recommendations and / or food and beverage purchase options can be provided to care providers and patients based on the collected data.

[0143] In some embodiments, methods for improving the productivity of care providers in VIP and advanced care are disclosed. Information collected using the aforementioned fixed sensors, wearable devices, equipment, hardware, and software can be combined with any of the following to improve the efficiency of care providers: (1) information about the needs and preferences of VIPs, (2) information about the skills and qualifications of shift care providers, (3) information about the current location of shift care providers relative to VIPs, (4) information about the relative importance and time required for shift care providers to complete their currently assigned tasks, (5) information about the current needs of other VIPs, and (6) information about the potential needs of other VIPs in the coming hours. Based on this information, the methods disclosed herein can instruct one or more specific care providers to perform tasks to care for the specific needs of a particular VIP, and can wait to see who accepts the task before notifying other VIPs. The methods and systems disclosed herein can also estimate and / or provide recommendations on whether and when to perform the instructed care intervention and by whom.

[0144] In some embodiments, platform 120 provides recommendations and / or areas for improvement at the care facility level, care provider organization level, and / or individual care provider level. In some embodiments, senior life operators overseeing multiple care facilities or communities can benefit from data-driven insights supported by platform 120 to improve operational efficiency and effectiveness.

[0145] Platform 120 collects and compares data from multiple care facilities operating under a single advanced life operator to help benchmark each facility and share best practices across various facilities. The types of data collected may include, but are not limited to, alarm frequency and type, time elapsed until a care provider responds to an alarm, time elapsed until an alarm is resolved, medication adherence levels, wandering and fall events (e.g., number of events, location of events, time of one or more events, individual who fell, etc.), and sleep quality. The collected data may include or be used to generate performance metrics for one or more care facilities. By comparing the performance metrics of each facility, Platform 120 can identify which facilities supervised by the advanced life operator may outperform other facilities supervised by the advanced life operator in a particular area. For example, a facility may have a significantly lower alarm response time due to the use of certain operational practices or specific technologies. In another example, a care facility may have fewer nighttime falls due to certain "best-in-class" operational practices. In these examples, the advanced life operator can identify these best practices and consider implementing them in other care facilities to improve overall performance and care levels. Conversely, it can provide the necessary resources or interventions to poorly performing institutions to improve the quality of care.

[0146] In some embodiments, Platform 120 analyzes staff performance metrics across different facilities operated by one or more senior life operators. Staff performance metrics may include data on individual care provider performance, alarm response performance time, etc. In some cases, patterns may emerge over time indicating that some care facilities have a large number of trained staff in areas with relatively low demand, while other care facilities may lack trained staff. Similarly, if a care facility has fewer alarms or problems (e.g., medication administration or fall incidents) in a particular area, and this correlates with a higher level of training in that area, it indicates that the training is highly effective. In this case, trained staff can be reallocated from facilities with a large number of trained staff or to other care facilities with a shortage of trained staff. Using the data and insights provided by Platform 120, senior life operators can make informed decisions about staff reallocation to more closely match the needs of each facility. Effective training programs can also be standardized across different care facilities to help ensure consistent quality of care. By aggregating and analyzing data from multiple facilities, Platform 120 provides advanced life operators with an overview of operations and helps them make strategic decisions to enhance the overall quality of care and operational efficiency.

[0147] In another embodiment, platform 120 can be integrated with an inventory system to monitor equipment and supply utilization, correlated with patient needs and alerts. Over time, patterns may emerge showing that some supplies are depleted faster than expected, or that some supplies are used more slowly than expected, or that they are not used at all. This allows for optimized procurement, minimizing waste, detecting supply shortages, and ensuring that necessary supplies are always in stock.

[0148] The embodiments discussed above illustrate the breadth of functionality in platform 120, including a comprehensive approach to enhancing functionality. This includes the productivity and effectiveness of care providers in caring for older adults and other patients, including those in residential care facilities. In some embodiments, platform 120 provides insights from data to support the effective management of care provider teams working in VIP and senior homes, ensuring optimal team performance and maintaining high-quality care.

[0149] In some embodiments, platform 120 records the number of alerts and insights generated by platform 120, as well as their corresponding response times for different teams and shifts. Such data can be combined with data on the number of available care providers, their skill levels, and the number of VIPs cared for during each shift. Thus, platform 120 can present information such as certain shifts consistently having slower response times to alerts, which may indicate staffing shortages or that particular shifts are more challenging due to the nature of the care required during those hours. In response, platform 120 can guide managers of care provider teams to consider adjusting staff allocations, such as ensuring more experienced care providers are available during challenging shifts, or introducing additional support and staffing during peak periods. This ensures VIPs receive timely attention, reduces risk, and improves the overall quality of care. In some embodiments, machine learning algorithms similar to those described above for generating insights and alerts can be applied across response time data to insights and alerts to suggest areas and shifts where additional staffing may be needed.

[0150] In another embodiment, Platform 120 uses data on frequently generated alarm types and post-intervention outcomes, and pairs this data with care provider profiles that detail the care provider's training history, areas of expertise, and feedback from VIPs or senior staff, to provide information to enhance care provider training and skills enhancement. For example, if a pattern emerges where a specific type of alarm (e.g., medication-related) is not effectively addressed within a care provider team, it can highlight knowledge or training gaps within the team. Conversely, if care providers consistently address these issues effectively, this may indicate that specialized training or skills should be shared across the entire care provider team. In such an example, care provider team managers can prioritize additional training courses or workshops focusing on identified areas requiring specialized training or skills. Care provider team managers can also facilitate peer learning, where experienced care providers share their expertise with the rest of the care team. Thus, Platform 120's data analytics capabilities can be leveraged at the care provider team management level to rapidly identify and address areas for improvement, leading to better care coordination, timely intervention, and ultimately enhanced VIP and senior well-being.

[0151] In some embodiments, Platform 120 can support improvements in individual caregiver performance, thereby enhancing the quality of care provided to VIPs and seniors, and fostering caregiver personal growth and job satisfaction. Platform 120 tracks the time individual caregivers spend processing and resolving 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 the caregiver's shift. If Platform 120 finds that a particular caregiver consistently spends longer than average response time processing a particular type of alert, it can highlight training needs or workload allocation issues. Caregiver managers are able to conduct one-on-one discussions to understand any challenges individual caregivers may be facing. Perhaps an individual caregiver needs more training in certain areas of care, or perhaps their shifts take them away from where most of their alerts originate, thus indicating a need for caregiver reassignment.

[0152] In some embodiments, Platform 120 further collects feedback on the resolution of alerts or insights to help improve the performance of individual care providers. Such feedback includes data from other care providers and collaborating staff and includes calculations of efficiency, effectiveness (e.g., the number of care providers requiring a response and their experience level, time to resolution, required supplies, the number of alerts generated and / or resolved for a VIP in a given period before and / or after the alert, etc.). For example, if a care provider consistently struggles to resolve certain types of problems effectively, it could be a prompt for: (1) targeted training or coaching for the care provider, (2) an assessment of whether the VIP or senior has an optimal care plan or whether adjustments are needed, and / or (3) whether sufficient care resources are available to work with that particular care provider. Care provider managers can then curate specific training modules, pair care providers with partners or mentors, or even suggest tracking more experienced care providers to enhance their skills. In such embodiments, the analytical capabilities of Platform 120 enable individual care providers not only to receive assistance in their current tasks but also to gain insights that can help build their professional development and proficiency. Therefore, improving the performance of individual care providers ultimately leads to better care outcomes for VIPs and older adults, and a more beneficial working environment for individual care providers.

[0153] Figure 5 illustrates a graphical user interface (GUI) of a care provider overview dashboard screen 500 according to some embodiments. The dashboard screen 500 includes multiple status blocks, each corresponding to an individual patient and providing information about the last event, 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, multiple activity 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 can be discussed below with reference to Figures 6, 7, and 8.

[0154] These status blocks utilize easily recognizable icons to consolidate dissimilar and previously unconnected data (e.g., medication adherence, sleep quality, and pain levels), enabling care providers to monitor vital vital data at a glance. This capability enhances the understanding of causal relationships, provides early insights into specific conditions, potentially before symptoms develop, and helps monitor progression toward alarm thresholds. Several exemplary status icons will be discussed below in conjunction with various sensors that can be used in conjunction with a specific patient and their living environment. Various other icons corresponding to other types of sensors not shown in Figures 6-8 may also be used and are included within the scope of embodiments of the disclosed invention.

[0155] Figure 6 illustrates a GUI for an exemplary first dashboard status block 600 for an individual patient according to some embodiments. Here, a patient named "Lea Sosa" is located in room 456. The last event was at 6:45 AM that day. Lea Sosa has 92 open alarms. Her "at home" icon 610, which can be triggered by a wearable device, indicates that she is at home (as it shows a house with someone inside) and that her status is normal (green). Heart icon 620 and danger icon 630 indicate that these items require checking (icons are orange). Medication icon 640 indicates that the medication dispenser is current (filled, showing three pills / tablets) and that patient Lea Sosa's medication is up-to-date (icon is green). Incontinence icon 650 indicates that she is clean (breasts show white, no diaper change required) and that the check is up-to-date (icon is green). Possible fall icon 660 is colored red, indicating that the care provider should register Lea Sosa in case of a possible fall. Bed icon 680 indicates that a check is needed (icon is orange) and that the patient is not in bed. The patient (VIP - vulnerable individual) check icon 670 is orange, indicating that Lea Sosa's patient check has expired, and the text below icon 670 indicates that the check expired 1 hour and 24 minutes ago. Additionally, the user can hold the mouse or touch any of the icons 610-680, and a small box (not shown) describing the icon and its current status will appear.

[0156] Figure 7 shows the 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 alarms are unchanged from the status shown in Figure 6. The Home (green) 710, Heart Monitor (orange) 720, and Danger (orange) icons 730 are unchanged compared to Figure 6. The Medication icon 740, compared to the Medication icon 640 in Figure 6, indicates that some pills are missing, suggesting the VIP missed a medication dose for some reason, and the care provider has turned off the "Missed Medication" alarm, and the patient is taking her medication on time (icon is green). The Incontinence icon 750 indicates that the incontinence pad is partially filled compared to the pad status shown in Figure 6, and the status is up-to-date (colored green). The Possible Fall icon 760 status remains unchanged compared to Figure 6. The Bed icon 780 is unchanged compared to Figure 6 and indicates a status requiring a check (icon is orange) and the patient is not in bed. The VIP Status Check icon 770 is gray, indicating that the patient's check sensor / time is currently not connected or expired.

[0157] Figure 8 shows the GUI of the third dashboard state 800 for the same individual patient "Lea Sosa" from Figures 6 and 7, according to some embodiments. The names, locations, last events, and numbers of open alarms are unchanged from the states shown in Figures 6 and 7. The Home (green) icon 810 indicates that the patient is not at home. The Heart Monitor (orange) icon 820 and the Danger (orange) icon 830 are unchanged compared to Figures 6 and 7. Compared to the Medication icon 640 in Figure 6, the Medication icon 840 still shows that some pills are missing, indicating that the VIP missed a medication dose for some reason, and the care provider has not turned off the "Missed Medication" alarm, and the patient is behind on taking her medication (icon in orange). The Incontinence icon 850 indicates that the incontinence pad is clean compared to the state of the pad shown in Figure 6, and the status check is expired (orange). The Possible Fall icon 860 is now orange, indicating that the status check may be expired but is not urgent (red), as shown in Figures 6 and 7. The Bed icon 680 indicates that a check is needed (icon in orange) and the patient is currently in bed. The VIP status check icon 870 is now green, indicating that the patient's sensor / time check is up-to-date and will expire in 4 minutes.

[0158] Figure 9 illustrates a graphical user interface (GUI) of an initial daily summary screen 900 according to some embodiments. The daily summary screen 900 shows legend 910, which illustrates color codes for daily summaries 920, 930, and 940, which display a 24-hour timeline in an "Overview" view for February 16, 2023 (the current day); February 15, 2023 (the previous day); and February 14, 2023. In some embodiments, the following patient status indicators are color-coded: "awake in bed," "asleep," "not in bed," "at home," "possibly not at home," and time point indicators for "event" (dot), "alarm" (triangle), and "scheduled care provider visit" (ellipse) for care provider visits. Events may include events recorded by sensors in the patient's residence or events worn by the patient. For example, in some embodiments, events recorded by sensors may include: medication dispensing, opening a teapot, getting out of bed, using the toilet, and using a walker. The status will no longer be displayed after 6:00 AM on the same day, because 6:00 AM represents the current time when the screenshot was taken.

[0159] Figure 10 illustrates a GUI of a first transition screen 1000 showing a first alarm 1050 according to some embodiments. Similar to Figure 9, the daily summary screen 1000 in Figure 10 shows a legend 1010, which displays color codes for daily summaries 1020, 1030, and 1040, which show a 24-hour timeline in an "Overview" view for February 16, 2023 (the current day); February 15, 2023 (the previous day); and February 14, 2023. In some embodiments, the following patient status indicators are color-coded: "awake in bed," "asleep," "not in bed," "at home," "possibly not at home," and time point indicators for "event" (dot), "alarm" (triangle), and "scheduled care provider visit" (ellipse) for care provider visits. Events may include events registered by sensors in the patient's residence or by sensors worn on the patient. For example, in some embodiments, events registered by the sensor may include events such as: dispensing medication, opening a teapot, getting up, going to the toilet, and using a walker. The status is no longer displayed after 6:00 AM, as 6:00 AM represents the current time when the screenshot was taken.

[0160] The cursor is positioned near 6:00 AM on the timeline for February 16, 2023, where notification box 1050 appears, indicating that, where the user has positioned cursor 1055, from 5:46 AM to 6:00 AM, patient John Smith was “not in bed at night.” A color code is displayed in red, indicating “out of bed” according to legend 1010. Events (blue dots) are present around the red band during this period, indicating events that might be noticed by the connected sleep pad (e.g., manufactured by Wiings) such as movement during sleep, snoring, heart rate changes, and / or sleep cycle tracking. The connected sleep pad or similar device can detect that the patient is not in bed.

[0161] Figure 11 illustrates a GUI of a second transition screen 1100 displaying a second alarm according to some embodiments. Similar to Figures 9 and 10, the daily summary screen 1100 in Figure 11 shows a legend 1110 that displays color codes for daily summaries 1120, 1130, and 1140, which show a 24-hour timeline in an "Overview" view for February 16, 2023 (the current day); February 15, 2023 (the previous day); and February 14, 2023. In some embodiments, the following patient status indicators are color-coded: "awake in bed," "asleep," "not in bed," "at home," "possibly not at home," and time point indicators for "event" (dot), "alarm" (triangle), and "scheduled care provider visit" (ellipse) for care provider visits. Events may include events recorded by sensors in the patient's residence or events worn on the patient. For example, in some embodiments, events recorded by the sensors may include: dispensing medication, opening a teapot, getting up, using the toilet, and using a walker. Statuses after 6:00 AM are no longer displayed for the current day, as 6:00 AM represents the current time when the screenshot was taken.

[0162] The cursor is positioned near 4 PM on the timeline at 11:30 on February 15, 2023. A notification box 1150 appears, indicating that the user has positioned the cursor at 1155. For a portion of the timeline spanning 4:27 PM to 5:18 PM, the patient John Smith is indicated by a diagonal yellow stripe in the color code "possibly not home," as indicated by legend 1110. Events (blue dots) occurring around the yellow stripe during this period indicate events that may have been detected by a door open sensor, wearable location sensor, or similar device, suggesting the patient may have left home and subsequently returned.

[0163] Figure 12 illustrates the GUI of a third transition screen 1200 displaying a third alert according to some embodiments. Similar to Figures 9-11, the daily summary screen 1200 in Figure 12 shows legend 1210, which displays color codes for daily summaries 1220, 1230, and 1240, showing a 24-hour timeline in an "Overview" view for February 16, 2023 (the current day); February 15, 2023 (the previous day); and February 14, 2023. In some embodiments, the following patient status indicators are color-coded: "awake in bed," "asleep," "not in bed," "at home," "possibly not at home," and time point indicators for "event" (dot), "alert" (triangle), and "scheduled care provider visit" (ellipse) for care provider visits. Events may include events recorded by sensors in the patient's residence or events worn by the patient. For example, in some embodiments, events recorded by sensors may include events such as: dispensing medication, turning on a teapot, getting out of bed, using the toilet, and using a walker. The status will no longer be displayed after 6:00 AM on the same day, because 6:00 AM represents the current time when the screenshot was taken.

[0164] The cursor is positioned above and near 9:00 AM on the timeline for February 15, 2023, where a notification box 1250 appears, indicating that the user has positioned cursor 1255 at 9:00 AM, and an alert notification (orange triangle) states that patient John Smith may have a “late wake-up time. It is 9:00 AM and Amba has detected that John is still in bed.” The orange triangle is the cursor's location, which, according to legend 1210, indicates “Alert.” Alerts and notifications can be recorded and / or triggered by a connected sleep pad and / or wearable position sensor, sleep sensor, CPAP device, or similar device that detects that the patient is still in bed and may be asleep.

[0165] Figure 13 illustrates the GUI of a fourth transition screen 1300 showing a table view 1330 of Wednesday, February 15, 2023, according to some embodiments. Similar to Figures 9-12, the Daily Summary screen 1300 in Figure 13 shows Legend 1310, which displays color codes for Daily Summaries 1320 and 1340, which show 24-hour timelines for February 16, 2023 (the day) and February 14, 2023, respectively, in an "Overview" view. In some embodiments, the following patient status indicators are color-coded: "Awake in bed," "Asleep," "Not in bed," "At home," "Possibly not at home," and time point indicators for "Event" (dot), "Alarm" (triangle), and "Scheduled care provider visit" (ellipse) for care provider visits. Events may include events recorded by sensors in the patient's residence or events worn on the patient. For example, in some embodiments, events recorded by the sensors may include: dispensing medication, opening a teapot, getting up, using the toilet, and using a walker. The status is no longer displayed after 6:00 AM, as 6:00 AM may be the current time when the screenshot was taken.

[0166] For February 15, 2023 (the previous day), the “Table” view is highlighted, and table view 1330 is shown, illustrating the timeline breakdown to “In Bed” time 1350, and events detected at “Front Door,” “Living Room,” and “Bathroom” 1360 (indicated by blue dots). These events may be noticed by door sensors or wearable position sensors or similar devices that detect that the patient may have entered 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 home and subsequently returned. In some embodiments, time spent in bed can be recorded via a connected sleep mat and / or wearable position sensors, sleep sensors, CPAP devices, or similar devices that detect whether the patient is still in bed and whether the patient is awake and in bed or asleep in bed.

[0167] Figure 14 illustrates the GUI of an initial analysis screen 1400 according to some embodiments, which displays the analysis graphically in color. The analysis screen 1400 allows dissimilar (but related) information to be presented meaningfully on the same chart or graph. For example, sleep scores, nighttime urination, and daily steps can be plotted together on a single chart. A care provider can view a single screen to see a summary of all collected sensor data (or selected sensor data) plotted on the graph for a specific time period. In some embodiments, the care provider may be able to see at a glance which metrics are approaching a level of concern, and / or cross into an alert zone by seeing if the metric is within the orange bands at the top and bottom of the graph 1420. In some embodiments, the orange bands correspond to upper and lower limits set by the care provider for a specific measurement for a particular individual.

[0168] In one embodiment shown in Figure 14, an analysis of a patient named John Smith is presented for the period from February 2nd to February 15th. In box 1410, the analysis can be filtered by, for example, health, sleep, and activity. In graph 1420, the analyses shown (selected by the care provider for display) include: average sleep heart rate, sleep duration, sleep score, time spent in bed, room humidity, and room temperature in the living room. In graph 1420 of Figure 14, the graph lines are depicted using colors corresponding to the legend 1430 of graph 1420.

[0169] Figure 15 illustrates a GUI of a first transition screen 1500 displaying analysis in a colored graphical form according to some embodiments. As shown in Figure 14, the analysis screen 1500 allows dissimilar (but related) information to be presented in a meaningful way on the same chart or graph. For example, sleep scores, nighttime urination, and daily steps can be plotted together on a single chart. A care provider can view a single screen to see a summary of all collected sensor data (or selected sensor data) plotted on the graph for a specific time period. In some embodiments, the care provider may be able to see at a glance which measures are approaching a level of concern, and / or cross into an alert zone by seeing if the measure is within the orange bands at the top and bottom of the graph 1520. In some embodiments, the orange bands correspond to upper and lower limits set by the care provider for a specific measurement for a particular individual.

[0170] In one embodiment shown in Figure 15, an analysis of a patient named John Smith is illustrated for the period from February 2nd to February 15th. In box 1510, the analysis can be filtered, for example, by health, sleep, and activity. Box 1410 shows a dropdown menu 1540 filtering the analysis by the "health" metric, where the user (e.g., care provider) has selected "Nighttime toilet visits daily count." In graph 1520, the analyses shown (selected by the care provider for display) include: average sleep heart rate, sleep duration, sleep score, time spent in bed, room humidity, and room temperature in the living room. The "Nighttime toilet visits daily count" metric is not yet depicted in graph 1520 because the user has just selected it. In graph 1520 of Figure 15, the curve is depicted using the colors according to the legend 1530 of graph 1520.

[0171] Figure 16 illustrates the GUI of a second transition screen 1600 according to some embodiments, which displays the analysis and filter selection by daily nighttime urination count in a colored graphical form. As shown in Figures 14 and 15, the analysis screen 1600 allows dissimilar (but related) information to be presented in a meaningful way on the same chart or graph. For example, sleep scores, nighttime urination, and daily steps can be plotted together on a single chart. Care providers can view a single screen to see a summary of all collected sensor data (or selected sensor data) plotted on the graph for a specific time period. In some embodiments, care providers can be able to see at a glance which measures are approaching a level of concern, and / or cross into an alert zone by seeing whether the measure is within the orange bands at the top and bottom of the graph 1620. In some embodiments, the orange bands correspond to upper and lower limits set by the care provider for a specific measurement for a particular individual.

[0172] In one embodiment shown in Figure 16, an analysis of a patient named John Smith is presented for the period from February 2nd to February 15th. In box 1610, the analysis can be filtered by, for example, health, sleep, and activity. Now, in menu bar 1640, a count for a "health" metric is shown in box 1610, where the user (e.g., care provider) has selected "Nighttime Toilet Visits Daily Count". In graph 1620, the analysis shown (selected by the care provider for display) includes: nighttime toilet visits daily count, average sleep heart rate, sleep duration, sleep score, bed rest time, room humidity, and living room temperature. The "Nighttime Toilet Visits Daily Count" metric is now shown in graph 1620 because the user selected this metric in the previous transition screen of Figure 15. In graph 1620 of Figure 16, the curve is depicted using the colors according to legend 1630 of graph 1620.

[0173] Figure 17 illustrates the GUI of a third transition screen 1700 according to some embodiments, which shows the analysis and filter selection by daily nighttime toilet attendance in a graphical form with shapes and dashes. As in Figures 14-16, the analysis screen 1700 allows dissimilar (but related) information to be presented in a meaningful way on the same chart or graph. A care provider can view a single screen to see a summary of all collected sensor data (or selected sensor data) plotted on the graph for a specific time period. In some embodiments, the care provider may be able to see at a glance which measures are approaching a level of concern, and / or cross into an alert zone by seeing if the measure is within the orange bands at the top and bottom of the graph 1720. In some embodiments, the orange bands correspond to upper and lower limits set by the care provider for a specific measurement for a particular individual.

[0174] In one embodiment shown in Figure 17, an analysis of a patient named John Smith is presented for the period from February 2nd to February 15th. In box 1710, the analysis can be filtered, for example, by health, sleep, and activity. Box 1710 shows counts for one "health" metric, four "sleep" metrics, and two "activity" metrics. In graph 1720, the analysis shown (selected by the care provider for display) includes: nighttime toilet attendance count, average sleep heart rate, sleep duration, sleep score, bed rest time, room humidity, and living room temperature. The user has toggled the graphics control 1740 to display "shapes and dashed lines" instead of "colors." Therefore, in graph 1720 of Figure 17, the curve is depicted using shapes and dashed lines according to the legend 1730 of graph 1720.

[0175] Figure 18 illustrates the GUI of a fourth transition screen 1800 according to some embodiments, which displays the analysis and filter selection for selected attributes in a colored graphical form. As in Figures 14-17, the analysis screen 1800 allows dissimilar (but related) information to be presented in a meaningful way on the same chart or graph. Care providers can view a single screen to see a summary of all collected sensor data (or selected sensor data) plotted graphically for a specific time period. In some embodiments, care providers can see at a glance which metrics are approaching a level of concern and / or cross into an alert zone by seeing if the metric is within the orange bands at the top and bottom of graph 1820. In some embodiments, the orange bands correspond to upper and lower limits set by the care provider for a specific measurement for a particular individual.

[0176] In one embodiment shown in FIG18, after the user switches the graphical control 1840 back to displaying "colors" instead of "shapes and dashed lines," the screen 1800 switches back to the screen shown in FIG16. Therefore, the settings in box 1810 and legend 1830 are the same as in FIG16. Furthermore, the graph 1820 of FIG18 is the same as that shown in graph 1620 of FIG16.

[0177] Figure 19 illustrates the GUI of a fifth transition screen 1900 according to some embodiments, showing analysis and filter selection for selected attributes in a colored graphical form, with the cursor highlighting the daily count of nighttime bathroom visits for one night. As in Figures 14-18, the analysis screen 1900 allows dissimilar (but related) information to be presented in a meaningful way on the same chart or graph. Care providers can view a single screen to see a summary of all collected sensor data (or selected sensor data) plotted graphically for a specific time period. In some embodiments, care providers may be able to see at a glance which measurements are approaching a level of concern, and / or cross into an alert zone by seeing if the measurement is within the orange bands at the top and bottom of the graph 1920. In some embodiments, the orange bands correspond to upper and lower limits set by the care provider for a specific measurement for a particular individual.

[0178] In one embodiment shown in Figure 19, an analysis of a patient named John Smith is presented for the period from February 2nd to February 15th. In box 1910, the analysis can be filtered by, for example, health, sleep, and activity. Box 1910 shows counts for one "health" metric, four "sleep" metrics, and two "activity" metrics. In graph 1920, the analysis shown (selected by the care provider for display) includes: daily nighttime toilet visits count, average sleep heart rate, average heart rate, etc., sleep rate in the living room, sleep duration, sleep score, time spent in bed, room humidity, and room temperature. The user has used the mouse to select graph plot 1950 for the daily nighttime toilet visits metric, causing other graph plots in graph 1920 to lighten to fade into the background, while graph plot 1950 remains in the same dark shade. The user has also moved the cursor 1960 to point to a local maximum on the "daily nighttime toilet visits count" curve 1950. Hovering cursor 1960 over the local maximum value makes the information text box 1940 visible, displaying a count of 12 for "Daily count of nighttime bathroom visits at 11:19 AM on Friday, February 10th". Furthermore, in graph 1920 of Figure 19, the curve is depicted using colors according to legend 1930.

[0179] Figure 20 illustrates the GUI of a sixth transition screen 2000 according to some embodiments, which shows the analysis and filter selections to attributes with only alerts in a colored graphical form. As in Figures 14-19, the analysis screen 2000 allows dissimilar (but related) information to be presented in a meaningful way on the same chart or graph. Care providers can view a single screen to see a summary of all collected sensor data (or selected sensor data) plotted graphically for a specific time period. In some embodiments, care providers can be able to see at a glance which measures are approaching a level of concern and / or cross into the alert zone by seeing whether the measure is within the orange bands at the top and bottom of the graph 2000. In some embodiments, the orange bands correspond to upper and lower limits set by the care provider for a specific measure for a particular individual.

[0180] In one embodiment shown in Figure 20, an analysis of a patient named John Smith is presented for the period from February 2nd to February 15th. In box 2010, the analysis can be filtered by, for example, health, sleep, and activity. However, in Figure 20, the user has chosen not to manually select the attributes to be displayed (e.g., measurement data), but instead has selected to display "Attributes with Alerts Only" via radio button selection menu 2040. Counts are 0. Box 2010 shows 2 "Health" metrics, 2 "Sleep" metrics, and 0 "Activity" metrics. In graph 2020, the analysis shown (selected by the care provider for display) includes only the two attributes with alerts for John Smith: wake-up count and bedridden time. In the graph 2020 of Figure 20, the curve is depicted using colors according to legend 2030.

[0181] In some embodiments, the analytics in Figures 14-20 can be used to orchestrate the behavior of devices and care providers to improve the efficiency, effectiveness, and quality of care. For example, in one embodiment, when a patient gets out of bed (sensor) or arrives at their kitchen (sensor), in addition to or instead of at a pre-programmed time, the medication dispenser can be programmed to ring or beep. In some embodiments, platform 120 can send reminders via a speaker to the patient's residence to prompt the patient to use their walker (sensor for detecting walker use) when they begin to get up at night, and to remind them again if the patient does not appear to be using it.

[0182] In some embodiments discussed above, platform 120 can provide alerts to indicate that a patient needs assistance (e.g., missed medication, getting out of bed and not using a walker, incontinence pad needing a change). In some embodiments, platform 120 can provide the ability to aggregate alerts, thereby enabling caregiving tasks to be combined into a single visit, thus optimizing care provider time and minimizing patient disruption. For example, if a patient is not in bed and needs to be visited to help them get back to bed, platform 120 can also identify that an incontinence pad will soon need a change, and / or medication will soon be taken, so the care provider will be assigned and instructed accordingly to handle all of the aforementioned tasks in a single visit, such as giving the patient their medication and changing the patient's incontinence pad before putting them back in bed. In some examples, alert settings can be set for each patient or resident based on specific concerns. For example, according to embodiments of this disclosure, alert settings can be established for each resident or patient who has discussed their concerns with a care provider, healthcare professional, and / or family member. In some examples, additional general alerts can be automatically activated to indicate changes in normal levels measured in the weeks (e.g., two weeks) prior to the deployment of platform 120 in a resident's or patient's living space.

[0183] In one example embodiment, platform 120 can be implemented in a nursing home or aged 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 alarm mechanisms. Thus, the example systems, apparatus, and methods described herein can be demonstrated as a significant reduction leading to falls, improved staff efficiency, and enhanced resident safety, thereby proving the effectiveness of integrated technologies in enhancing human support within resident care settings.

[0184] In particular, fall management using traditional methods such as sensor pads and physical examinations has proven to have significant limitations, especially for residents or patients identified as high-risk for falls. For example, sensor pads may not be entirely reliable, as some residents may bypass them, resulting in unmonitored bed exits. Furthermore, sensor pads may pose a tripping hazard to some residents. Additionally, having staff perform regular physical examinations of high-risk residents (e.g., every 30 minutes) is a labor-intensive process that can be difficult to maintain consistently and is disruptive to residents and patients. Therefore, while diligent, traditional methods can sometimes lead to delayed responses, where the first indication of a fall is the sound of the fall itself or the next scheduled physical examination.

[0185] One example implementation of Platform 120 can use a real-time alarm mechanism as described herein to enhance fall detection and response time. In such an example embodiment, Platform 120 may include at least the following components: a sleep monitoring device, motion sensors, and a door. The sleep monitoring device tracks the occupant's movement in bed and promptly alerts staff when the occupant leaves the bed. Motion sensors installed in the occupant's room and adjacent areas (e.g., the bathroom) detect the occupant's movement and trigger alarms to staff using Platform 120. Similarly, door sensors monitor door activity, providing additional contextual information about the occupant's activities. This exemplary implementation of Platform 120 is used to quickly notify staff when a occupant is in danger, allowing staff to respond more rapidly and effectively.

[0186] In one embodiment, such an exemplary implementation is shown as having a dramatic reduction in nighttime falls. For example, prior to the installation of the exemplary implementation of Platform 120, a care facility in the UK recorded 44 falls in a particular month. After the installation of the exemplary implementation of Platform 120 as described above, the number of falls at the same facility dropped to 9 the following month, representing a reduction of 79%. This significant reduction highlights the effectiveness of the implementation of Platform 120 in mitigating the risk of falls. In this embodiment, a detailed analysis was conducted to identify whether any other variables could contribute to this improvement, but the analysis showed that the introduction of the exemplary implementation of Platform 120 supported more proactive action by staff, resulting in a dramatic reduction in the number of falls among residents and enhanced resident safety. The main alarm that produced a significant difference in the exemplary implementation was the nighttime bed-out alarm. If a patient leaves their bed at night, the care provider is immediately alerted, allowing the care provider to quickly attend to the patient as this can indicate a concern. Other relevant alarms include a relatively low sleep score (indicating poor sleep among residents) and a relatively high sleep heart rate (indicating an early sign of possible infection). Both of these alarms indicate an increased risk of falls and therefore suggest a need for increased vigilance from care providers when checking on affected residents or patients. This reduction in falls directly impacts residents' health, decreasing the incidence of injuries and the need for emergency medical intervention. Furthermore, this example implementation of Platform 120 allows staff to monitor residents without continuous physical intrusion, thereby promoting resident independence and creating a more comfortable and safer environment for them.

[0187] Furthermore, this exemplary implementation of Platform 120 is shown to significantly reduce the need for continuous physical examinations of residents, thereby alleviating staff workload. With real-time alerts, staff can focus on immediate risks and planned care and support, rather than routine physical examinations, thus allocating staff time and resources more efficiently. Staff feedback in the exemplary implementation of Platform 120 indicates that the reduction in manual routine examinations lowers staff stress levels, allowing staff to provide higher overall quality of care. Further improvements to the exemplary implementation of Platform 120 can monitor and adjust the system to further reduce falls during the day (in addition to reducing falls at night) and in public areas. Additionally, further enhancements to the exemplary implementation of Platform 120 can integrate Platform 120 with existing care management systems to reduce duplication of records and streamline document processing at care facilities. Therefore, this exemplary implementation of Platform 120 demonstrates significant positive impacts on enhancing human support in the care environment. The significant reduction in falls, increased staff efficiency, and enhanced resident safety underscore the value of integrating advanced monitoring systems into care facilities.

[0188] In another example implementation of Platform 120 in a comprehensive retirement community in the United States (combining independent living, assisted living, and memory care), the quality of care has shown significant improvement since the installation of Platform 120. For example, resident falls have similarly decreased month by month since the installation of Platform 120. Resident readmission rates have decreased. Sensors that can be used in example implementations of Platform 120 that reduce hospitalizations could include an electronic medication dispenser that reminds residents to take their medications and alerts care providers if they miss a dose. In such an example, care providers can see whether a resident is at home or in bed and decide whether to call or visit the patient to check on them to ensure there are no problems, and / or remind them to take their medications. Another example of sensors that could be used to help reduce hospitalizations could include an incontinence sensor that detects the need to change incontinence pads and can reduce skin irritation and infection, which can be a major cause of hospitalizations.

[0189] Furthermore, the impact on psychotropic medication administration was reduced by more than 50%. Factors contributing to the reduction in psychotropic medication use can be directly attributed to the implementation of Platform 120, as it provides care providers with information that can help explain certain behaviors of residents or patients (e.g., disruptive behaviors at certain times of day might be caused by factors such as poor sleep at night, infection symptoms, excessive daytime sleep, or insufficient exercise). In such an example implementation, care providers can use the information provided by Platform 120 to intervene and address these concerning issues before resorting to psychotropic medications.

[0190] Regarding infection risk, data from an example implementation of Platform 120 demonstrates when an infection might be occurring. As described above, baseline indicators have been identified and added to residents' profiles to automatically flag high infection risks. For example, early signs of infection might include one or more of the following proactive alerts: low sleep score, high sleep heart rate, high sleep breathing rate, increased breathing disturbances, increased nighttime urination. In some examples, if one or more of these alerts are active, care providers can decide to test for infection earlier than they would normally would, and (if an infection is detected) to begin treatment earlier than they would normally would, thereby preventing infection. The severity of the infection can be capped and lowered for any of the numerous data measurements on the disclosed platform. For example, baseline values ​​can be set across the entire organization or a group of residents or patients. Alternatively, baseline values ​​can be set automatically based on individual measurement data, or they can be set manually for each individual. In some examples, alert types for individual data points being too high or too low are supported. In other examples, combinations of one or more data points that are too high or too low can be supported.

[0191] The systems, apparatus, and methods described herein can be implemented using digital circuitry or using one or more computers employing 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 disks, internal hard disks and removable disks, magneto-optical disks, optical disks, etc.

[0192] Figure 21 illustrates a high-level block diagram of an exemplary apparatus that can be used to implement the systems, devices, and methods described herein. Apparatus 2100 includes a processor 2110 operatively coupled to persistent storage device 2120 and main memory device 2130. Processor 2110 controls the overall operation of apparatus 2100 by executing computer program instructions that define such operation. 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 is desired. Therefore, the method steps of Figures 3 and 4 can be defined by computer program instructions stored in main memory device 2130 and / or persistent storage device 2120 and controlled by processor 2110 that executes the computer program instructions. For example, the computer program instructions may be implemented as a computer-readable medium. Executable code, programmed by those skilled in the art, is used to execute the algorithm defined by the method steps of Figures 3 and 4. Thus, by executing the computer program instructions, processor 2110 executes the algorithm defined by the method steps of Figures 3 and 4. The device 2100 also includes one or more network interfaces 2180 for communicating with other devices via a network. The device 2100 may also include one or more input / output devices 2190 (e.g., display, keyboard, mouse, speaker, button, etc.) that enable a user to interact with the device 2100.

[0193] Processor 2110 may include both general-purpose and special-purpose microprocessors, and may be the sole processor of device 2100 or one of multiple processors. Processor 2110 may include one or more central processing units (CPUs) and one or more graphics processing units (GPUs), which may, for example, operate independently of one or more CPUs and / or perform multitasking with one or more CPUs to accelerate processing, for example, for the various image processing applications described herein. Processor 2110, persistent storage device 2120, and / or main memory device 2130 may include one or more application-specific integrated circuits (ASICs) and / or one or more field-programmable gate arrays (FPGAs), supplemented or incorporated therein.

[0194] Persistent storage device 2120 and main memory device 2130 each include 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 disk storage devices, such as internal hard disks and removable disk read-only memory (CD-ROM), digital universal disk read-only memory (DVD-ROM), or other non-volatile solid-state storage devices.

[0195] Input / output device 2190 may include peripheral devices such as printers, scanners, displays, etc. For example, input / output device 2190 may include display devices (such as cathode ray tube (CRT), plasma or liquid crystal display (LCD) monitors) for displaying information to a user, a keyboard, and indicating devices (such as mice or trackballs) through which the user can provide input to device 2100.

[0196] Any or all of the functions of the systems and apparatuses discussed herein can be executed by processor 2110. Furthermore, apparatus 2100 can utilize one or more neural networks or other deep learning techniques executed by processor 2110 or other systems or apparatuses discussed herein.

[0197] Those skilled in the art will recognize that the implementation of an actual computer or computer system may have other structures and may contain other components, and Figure 21 is a high-level representation of some of the components of this computer for illustrative purposes.

[0198] Throughout the specification and claims, unless the context clearly specifies otherwise, the following terms shall have the meanings explicitly applicable herein:

[0199] The phrase "in one embodiment" as used herein does not necessarily refer to the same embodiment, although it may refer to the same embodiment. Therefore, as described below, various embodiments of the invention can be readily combined without departing from the scope or spirit of the invention.

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

[0201] The term "based on" is not exclusive and may be based on additional factors not described unless the context clearly specifies otherwise.

[0202] As used herein, and unless the context otherwise requires, the term “coupled to” is intended to include both direct coupling (where two elements coupled to each other are in contact with each other) and indirect coupling (where at least one additional element is located between the two elements). Therefore, the terms “coupled to” and “coupled with” are used synonymously. In the context of a networked environment in which two or more components or devices are able to exchange data, the terms “coupled to” and “coupled with” are also used to indicate possible “communicative coupling” via one or more intermediate devices.

[0203] While some of the various embodiments presented herein constitute a single combination of inventive elements, it should be understood that the inventive subject matter is considered to include all possible combinations of the disclosed elements. Therefore, if one embodiment includes elements A, B, and C, and another embodiment includes elements B and D, the inventive subject matter is also considered to include other remaining combinations of A, B, C, or D, even if not explicitly discussed herein. Furthermore, the transitional term "comprising" means having as a component or element, or those components or elements. As used herein, the transitional term "including" is inclusive or open-ended and does not exclude additional, unlisted elements or method steps.

[0204] Throughout this disclosure, numerous references may be made to servers, services, interfaces, engines, modules, clients, peers, portals, platforms, or other systems formed by computing devices. It should be understood that the use of these terms is considered to refer to one or more computing devices having at least one processor (e.g., ASIC, FPGA, DSP, x86, ARM, ColdFire, GPU, multi-core processor, etc.) configured to execute software instructions stored on a computer-readable tangible non-transitory medium. Memory (e.g., hard disk drive, solid-state drive, RAM, flash memory, ROM, etc.). For example, a server may include one or more computers operating as a web server, database server, or other type of computer server in a manner that fulfills the described roles, responsibilities, or functions. It should be further understood that the disclosed computer-based algorithms, processes, methods, or other types of instruction sets may be embodied as computer program products comprising a non-transitory tangible computer-readable medium storing instructions that cause a processor to perform the disclosed steps. Various servers, systems, databases, or interfaces may exchange data using standardized protocols or algorithms, possibly based on HTTP, HTTPS, AES, public-key-private-key exchange, web service APIs, or other electronic information exchange methods. Data exchange can be conducted through packet-switched networks, circuit-switched networks, the Internet, LANs, WANs, VPNs, or other types of networks.

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

[0206] It should be noted that any language intended for computers should be understood 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 in combination. It should be understood that computing devices include processors configured to execute software instructions stored on tangible, non-transitory computer-readable storage media (e.g., hard disk drives, FPGAs, PLAs, solid-state drives, RAM, flash memory, ROM, etc.). These software instructions configure or program the computing device to provide roles, responsibilities, or other functions, as discussed below with respect to the disclosed apparatus. Furthermore, the disclosed technology can be embodied as a computer program product comprising a non-transitory computer-readable medium storing software instructions that cause a processor to perform the disclosed steps associated with an implementation of a computer-based algorithm, process, method, or other instructions. In some embodiments, various servers, systems, databases, or interfaces exchange data using standardized protocols or algorithms, possibly based on HTTP, HTTPS, AES, public-key-private-key exchange, web service APIs, known financial transaction protocols, or other electronic information exchange methods. Data exchange between devices can be conducted through packet-switched networks, the Internet, LANs, WANs, VPNs, or other types of packet-switched networks; circuit-switched networks; cell-switched networks; or other types of networks.

[0207] The foregoing description should be understood as illustrative and exemplary in all respects, and not restrictive. The scope of the invention disclosed herein is not determined by the description, but by the claims interpreted according to the full scope permitted by patent law. It should be understood that the embodiments shown and described herein are merely for illustrating the principles of the invention, and various modifications can be made by those skilled in the art without departing from the scope and spirit of the invention. Various other combinations of features can be implemented by those skilled in the art without departing from the scope and spirit of the invention.

Claims

1. A method for generating one or more nursing alerts for one or more patients, the method comprising: a. Receive real-time or near-real-time measurement data from one or more sensors located in the living environment of the first patient among the one or more patients; b. Using real-time or near-real-time measurement data from one or more sensors to generate a status report for a first patient; c. Using real-time or near-real-time measurement data from one or more sensors of the first patient to identify at least one rule related to the first patient from an individual rule engine, wherein the identified rule is applied to generate at least one alarm indicator for the first patient, wherein the alarm indicator includes an emergency alarm, a warning alarm, or a stabilization alarm; d. Using real-time or near-real-time measurement data from one or more sensors of the first patient and measurement data from a patient group, identifying at least one rule from a group rule engine to apply to the first patient, 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 care provider's device, wherein the user interface displays the real-time or near-real-time measurement data of the first patient, the status report, the alarm indicator, and the health assessment.

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

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

4. The method according to claim 1, wherein, The first patient lived in a private residence.

5. The method according to claim 1, wherein, The care provider's device is located away from the living environment of the first patient.

6. The method according to claim 1, wherein, The alarm indicators include at least one of the following: in-bed alarm, out-of-bed alarm, door open alarm, appliance open alarm, possible fall alarm, incontinence alarm, missed medication alarm, late bedtime alarm, late arrival home alarm, patient out of bounds alarm, inactivity alarm, measurement result out of bounds alarm, configurable measurement result alarm, or appliance off alarm.

7. The method of claim 1, further comprising sending a push notification, text message, short message service (SMS), or telephone call to the user device of the care provider of the alarm indicator.

8. The method of claim 1, wherein the patient group includes the one or more patients.

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

10. The method according to claim 1, further comprising: a. When generating the emergency alert indicator for the first patient’s at least one rule, an emergency care request is generated for the first patient, the emergency care request including caregiver qualifications, location, duration and a list of supplies; b. Analyze one or more care provider profiles, wherein the care provider profile includes care provider qualifications, current location, remaining time of the current shift, supply inventory, and standby status; c. Identify the care provider profile, current location, remaining time of the current shift, and supply inventory matching the emergency care request for the first patient for care providers with care provider qualifications; and d. Send an instruction alert to the user device of the identified care provider to fulfill the emergency care request for the first patient.

11. The method of claim 10, further comprising: a. Identify multiple care provider profiles, wherein each care provider profile is associated with a care provider who has care provider qualifications, current location, remaining time on the current shift, and a supply inventory that generates a match for the emergency care request for the first patient; b. Send an instruction alert to the user device of each of the matched care providers to fulfill the emergency care request; and c. Upon receiving acceptance from a matched care provider, send an instruction alert to the other matched care providers notifying them that the request 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, each record being associated with a specific patient among the one or more patients, and including one or more patient settings; b. A patient measurement database comprising a second plurality of records, each record being associated with a specific patient among the patients; wherein at least one healthcare data attribute includes real-time or near-real-time measurement data received from one or more sensors located in the living environment of a first patient among the one or more patients; c. An individual rule engine connected to the patient settings database and the patient measurement results database, wherein the individual rule engine is configured for the first patient among the one or more patients to: i. receive 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, use measurement data corresponding to the first patient from the patient measurement database to identify at least one individual rule to be applied to the first patient, wherein the identified individual rule is used to generate a rule for the first patient among the one or more patients. The system comprises: d. a patient status report and one or more alarm indicators, wherein the alarm indicators include an emergency alarm, a caution alarm, or a stable alarm; d. a group rule engine connected to the patient settings database and the patient measurement results database, wherein the group rule engine is configured for the first patient among the one or more patients to: i. receive 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 group rule to be applied to the first patient using (1) measurement data corresponding to the first patient from the patient measurement database and (2) measurement data from the patient group, wherein the identified group rule is applied to generate a health assessment for the first patient; and iii. a reporting module configured to generate and send a user interface for display on a care provider's device, wherein the user interface displays one or more of the following: the real-time or near-real-time measurement data of the first patient, the status report, the alarm indicators, and the health assessment.

13. The system according to claim 12, wherein, At least one of the one or more patients lives in a nursing facility.

14. The system according to claim 12, wherein, At least one of the patients lives in a private residence.

15. The system according to claim 12, wherein, The care provider's device is located away from the living environment of the first patient.

16. The system according to claim 12, wherein, The alarm indicators include at least one of the following: in-bed alarm, out-of-bed alarm, door open alarm, appliance open alarm, possible fall alarm, incontinence alarm, missed medication alarm, late bedtime alarm, late arrival home alarm, patient out of bounds alarm, inactivity alarm, measurement result out of bounds alarm, configurable measurement result alarm, or appliance off alarm.

17. The system of claim 12 further includes sending a push notification, text message, short message service (SMS), or telephone call to the user device of the care provider of the alarm indicator.

18. The system according to claim 12, wherein, The patient group includes the one or more patients.

19. The system according to claim 12, wherein, The patient population includes longitudinal studies of patients.

20. The system according to claim 12, wherein, The reporting module also performs the following operations: a. Upon receiving the emergency alert indicator for the first patient under at least one rule, it generates an emergency care request for the first patient, including the qualifications, location, duration, and list of supplies of the care provider; b. Analyze one or more care provider profiles, wherein the care provider profile includes care provider qualifications, current location, remaining time of the current shift, supply inventory, and standby status; c. Identify the care provider profile, current location, remaining time of the current shift, and supply inventory matching the emergency care request for the first patient for care providers with care provider qualifications; and d. Send an instruction alert to the user device of the identified care provider to fulfill the emergency care request for the first patient.

21. The system according to claim 20, wherein, The reporting module also performs the following operations: a. identifying multiple care provider profiles, wherein each care provider profile is associated with a qualified care provider, current location, remaining time of the current shift, and generating a supply inventory that matches the emergency care request for the first patient; b. sending an instruction alert to the user device of each of the matched care providers to fulfill the emergency care request; and c. upon receiving acceptance from a matched care provider, sending an instruction alert notification to the other matched care providers that the request has been fulfilled.

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

23. The system according to claim 22, wherein, The insight module uses machine learning algorithms applied to the measurement data of the one or more patients to generate one or more individual rules, group rules, or patient setting modifications.

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 the living environment of a first patient among the one or more patients; b. Generate a status report for the first patient using real-time or near-real-time measurement data from one or more sensors; c. Identify at least one rule related to the first patient from an individual rule engine using real-time or near-real-time measurement data from one or more sensors of the first patient, wherein, The identified rules are applied to generate at least one alarm indicator for the first patient, wherein the alarm indicator includes an emergency alarm, a warning alarm, or a stabilizing alarm; d. Using real-time or near-real-time measurement data from one or more sensors of the first patient and measurement data from the patient population, at least one rule is identified from a population rule engine to be applied to the first patient, wherein the identified rule is applied to generate a health assessment for the first patient; and e. A user interface is generated for display on a care provider's device, wherein the user interface displays the real-time or near-real-time measurement data of the first patient, the status report, the alarm indicator, and the health assessment.

Images