Systems and methods for contactless monitoring

Abstract

A system and method for monitoring a health status of a patient using one or more radar sensors placed in an environment containing the patient. A processor controls the radar sensors to emit radio waves and measures reflection data including reflected radio waves. The processor processes the reflection data to determine motion state data characterizing position and velocity, isolates motion state data associated with human movement patterns to generate tracked motion state data, and aggregates the tracked motion state data to generate aggregate motion data. Machine learning algorithms process the aggregate motion data to determine health status including fall detection, behavior identification, and characterization of Alzheimer's disease, dementia, Parkinson's disease, fall risk, and sundowning. The system tracks aggregate motion data longitudinally over time and generates reports based on health status.

Description

Client Ref. UMN 2025-119SYSTEMS AND METHODS FOR CONTACTLESS MONITORINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on, claims priority to, and incorporates herein by reference for all purposes, U.S. Provisional Patent Application No. 63 / 740,576 filed on December 31, 2024.BACKGROUND

[0002] Falls are the leading cause of injuries among people aged 65 and older, with estimated yearly direct medical costs of $637.2 million for fatal falls and $31.3 billion for nonfatal falls in the United States. Furthermore, those with dementia living in nursing care facilities fall 4.1 times per year on average versus 2.3 times for other residents. The potential for a fall detection product to reduce costs and hospital admissions and improve outcomes is significant.

[0003] Virtual care at home is growing in importance as an approach to healthcare. The aging population and their care needs present challenges in the size and scope as an estimated 6.2 million Americans aged 65 or older live with Alzheimer’s Disease and Alzheimer’s Disease Related Dementias [AD / ADRD] in the United States, and 55 million globally. The "gray tsunami” is a global challenge as the UN estimates the total aging population to be over 3 billion people worldwide by 2030.

[0004] The COVID-19 pandemic increased the use of digital health and awareness of the need for technology that augments the work of clinicians. Even with this paradigm shift in perspective the healthcare infrastructure has significant developments that need to occur by 2030 to care for the aging population as approximately 10,000 people turn 65 each day in the US.

[0005] Traditional health monitoring for elderly or cognitively impaired-1- QB\920171.00672\100158611.4Client Ref. UMN 2025-119individuals often relies on wearable devices, such as accelerometers for actigraphy. However, these devices can be intrusive and may not capture or analyze subtle movement patterns or trends indicative of neurodegenerative conditions like Alzheimer's disease. Moreover, wearable devices require consistent usage, which is often impractical for many individuals. Other solutions have employed camera-based surveillance, which present significant privacy concerns, especially in sensitive areas such as bedrooms and bathrooms, which has led to low adoption rates. Thus, there remains a need for real-time, noninvasive, and contactless solution for fall detection and monitoring health status of at-risk individuals, like elderly and AD / ADRD patients.SUMMARY OF THE DISCLOSURE

[0006] The present disclosure addresses the aforementioned drawbacks by providing a system and method for monitoring a health status of a patient in a noninvasive, contactless, and private way. The systems and methods described provide computational advantages, with convenient, flexible, and affordable use, allowing monitoring to be scaled, for example, to fully cover a patient’s residence or to monitor patients across a care facility.

[0007] The present invention provides a system for monitoring a health status of a patient. The system includes one or more radar sensors configured to be placed in an environment containing a patient and a processor. The processor is configured to control the one or more radar sensors to emit radio waves into the environment and measure reflection data including reflected radio waves reflected by the environment. The processor processes the reflection data to determine motion state data, wherein the motion state data characterizes a position and velocity for each datapoint of the reflection data. The processor further processes the motion state data to isolate motion state data-2- QB\920171.00672\100158611.4Client Ref. UMN 2025-119associated with human movement patterns to generate tracked motion state data, aggregates the tracked motion state data to generate aggregate motion data, processes the aggregate motion data to determine a health status of the patient, and generates a report based on the health status of the patient.

[0008] In various embodiments, the aggregate motion data characterize at least one of a summarized height metric that describes a z-coordinate of the tracked motion state data, a summarized position metric that describes a position of the tracked motion state data, a summarized velocity metric that describes a change of position of the tracked motion state data in time, a summarized acceleration metric that describes a change of velocity of the tracked motion state data in time, a summarized derivative metric that describes a temporal derivative of position of the tracked motion state data in time, or an aggregate activity data.

[0009] In some embodiments, processing the aggregate motion data to determine the health status of the patient includes applying a machine learning algorithm that identifies a fall of the patient according to at least one of the summarized height metric, the summarized position metric, the summarized velocity metric, the summarized acceleration metric, or the summarized derivative metric through time.

[0010] In some embodiments, processing the aggregate motion data to determine the health status of the patient includes applying a machine learning algorithm that identifies a behavior of the patient according to the summarized height metric through time, wherein the behavior includes one of sitting, sleeping, walking, or being on the floor.

[0011] In some embodiments, the processor is further configured to transmit the aggregate motion data to a memory configured to store the aggregate activity data longitudinally over time.

[0012] In some embodiments, processing the aggregate motion data to determine -3- QB\920171.00672\100158611.4Client Ref. UMN 2025-119the health status of the patient includes tracking the aggregate motion data longitudinally and applying a machine learning algorithm that characterizes a status of at least one of Alzheimer's disease, dementia, Alzheimer's disease related dementia, Parkinson's disease, or fall risk of the patient according to a longitudinal change in the aggregate activity data.

[0013] In some embodiments, the aggregate motion data further characterize a measurement time, and processing the aggregate motion data to determine the health status of the patient includes tracking the aggregate motion data longitudinally and applying a machine learning algorithm that characterizes a status of sundowning based on a longitudinal change in the time-dependent aggregate activity data.

[0014] In some embodiments, processing the motion state data to isolate motion state data associated with human movement patterns includes applying density-based clustering algorithms to the motion state data.

[0015] In some embodiments, processing the motion state data to isolate motion state data associated with human movement patterns includes applying a trained convolutional neural network based on a micro-Doppler signature of the reflection data.

[0016] In some embodiments, processing the motion state data to isolate motion state data associated with human movement patterns includes filtering the motion state data to discard at least one of motion state data with low signal to noise ratio or motion state data associated with static velocities.

[0017] In some embodiments, aggregating the tracked motion state data includes applying statistical methods to determine the summarized height metric that describes the z-coordinate of the tracked motion state data and discarding associated x- and y-coordinates of the tracked motion state data. In further embodiments, aggregating the tracked motion state data further includes discarding velocities associated with the .4.QB\920171.00672\100158611.4Client Ref. UMN 2025-119tracked motion state data.

[0018] In some embodiments, aggregating the tracked motion state data includes summing a number of tracked motion state data points in each frame to characterize the aggregate activity data.

[0019] In some embodiments, the one or more radar sensors include a plurality of radar sensors arranged in an array, and the reflection data include reflected radio waves measured by a combination of at least two of the plurality of radar sensors.

[0020] In some embodiments, the radio waves emitted by the radar sensors are frequency modulated continuous waves. In further embodiments, the radio waves have a frequency modulated pattern characterized by a chirp.

[0021] The present invention further provides a method for monitoring a health status of a patient. The method includes steps of placing one or more radar sensors in an environment containing a patient and using a processor to control the one or more radar sensors to emit radio waves into the environment, measure reflection data including reflected radio waves reflected by the environment, process the reflection data to determine motion state data characterizing a position and velocity for each datapoint of the reflection data, process the motion state data to isolate motion state data associated with human movement patterns to generate tracked motion state data, aggregate the tracked motion state data to generate aggregate motion data, process the aggregate motion data to determine a health status of the patient, and generate a report based on the health status of the patient.

[0022] In various embodiments of the method, the aggregate motion data characterize at least one of a summarized height metric that describes a z-coordinate of the tracked motion state data, a summarized position metric that describes a position of the tracked motion state data, a summarized velocity metric that describes a change of -5- QB\920171.00672\100158611.4Client Ref. UMN 2025-119position of the tracked motion state data in time, a summarized acceleration metric that describes a change of velocity of the tracked motion state data in time, a summarized derivative metric that describes a temporal derivative of position of the tracked motion state data in time, or an aggregate activity data.

[0023] In some embodiments of the method, processing the aggregate motion data to determine the health status of the patient includes applying a machine learning algorithm that identifies a fall of the patient according to at least one of the summarized height metric, the summarized position metric, the summarized velocity metric, the summarized acceleration metric, or the summarized derivative metric through time.

[0024] In some embodiments of the method, processing the aggregate motion data to determine the health status of the patient includes applying a machine learning algorithm that identifies a behavior of the patient according to the summarized height metric through time, wherein the behavior includes one of sitting, sleeping, walking, or being on the floor.

[0025] In some embodiments of the method, the processor is further configured to transmit the aggregate motion data to a memory configured to store the aggregate activity data longitudinally over time.

[0026] In some embodiments of the method, processing the aggregate motion data to determine the health status of the patient includes tracking the aggregate motion data longitudinally and applying a machine learning algorithm that characterizes a status of at least one of Alzheimer's disease, dementia, Alzheimer's disease related dementia, Parkinson's disease, or fall risk of the patient according to a longitudinal change in the aggregate activity data.

[0027] In some embodiments of the method, the aggregate motion data further characterize a measurement time, and processing the aggregate motion data to -6- QB\920171.00672\100158611.4Client Ref. UMN 2025-119determine the health status of the patient includes tracking the aggregate motion data longitudinally and applying a machine learning algorithm that characterizes a status of sundowning based on a longitudinal change in the time-dependent aggregate activity data.

[0028] The present invention further provides a method for monitoring a health status of a patient including steps of placing one or more radar sensors in an environment containing a patient and using a processor to control the one or more radar sensors to emit radio waves into the environment, measure reflection data including reflected radio waves reflected by the environment, process the reflection data to determine motion state data characterizing a position and velocity for each datapoint of the reflection data, process the motion state data to generate micro-Doppler analysis data that characterize a micro-Doppler signature of the motion state data, process the micro-Doppler analysis data to determine vital sign data of the patient that characterizes at least one of a respiratory rate or pulse rate of the patient, and generate a report based on the vital sign data of the patient.

[0029] In some embodiments, the patient is an infant, and the method further includes using the processor to process the vital sign data to determine a risk level of sudden infant death syndrome, wherein the report is further based on the determined risk level.

[0030] These are but a few, non-limiting examples of aspects of the present disclosures. Other features, aspects and implementation details will be described hereinafter.BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Various objects, features, and advantages of the disclosed subject matter-7- QB\920171.00672\100158611.4Client Ref. UMN 2025-119can be more fully appreciated with reference to the following detailed description of the disclosed subject matter when considered in connection with the following drawings, in which like reference numerals identify like elements.

[0032] FIG. 1A shows a schematic drawing of an example user device.

[0033] FIG. IB shows a block diagram illustrating a scalable patient monitoring system.

[0034] FIG. 2 provides a flowchart setting for steps of an example process for monitoring the health status of a patient.

[0035] FIG. 3 is a block diagram showing an example implementation of a health monitoring system.

[0036] FIG.4A shows example simulated activity data over a week.

[0037] FIG.4B shows example simulated activity data over a year and correlations with cognitive scores.

[0038] FIG.5 shows a flowchart that illustrates a process for monitoring the health status of a patient in an example implementation.

[0039] FIG. 6 shows a flowchart that illustrates an example implementation of a computational architecture that can be used for monitoring the health status of a patient.

[0040] FIG. 7A schematically shows a non-limiting example of a sensor arrangement in a memory care residence in 2D.

[0041] FIG. 7B schematically shows a non-limiting example of a sensor arrangement in a memory care residence in 3D.

[0042] FIG.8 schematically shows a non-limiting example of a sensor arrangement throughout a memory care facility.

[0043] FIG.9 shows an example user device.

[0044] FIG. 10 shows example experimental data tracking activity for a patient -8- QB\920171.00672\100158611.4Client Ref. UMN 2025-119through time.

[0045] FIG. 11 shows example experimental data tracking activity for a patient through space using multiple sensors.

[0046] FIG. 12 illustrates an example pipeline used for monitoring the health status of a patient.

[0047] FIG. 13 is a block diagram of an example health monitoring system that can implement the methods of the present disclosure.

[0048] FIG. 14 is a block diagram of example components that can implement the system of FIG. 13.DETAILED DESCRIPTION

[0049] Before any aspects of the present disclosure are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of "including,” "comprising,” or "having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms "mounted,” "connected,” "supported,” and "coupled” and variations thereof are used broadly and encompass both direct and indirect mountings, connections, supports, and couplings. Further, "connected” and "coupled” are not restricted to physical or mechanical connections or couplings.

[0050] The following discussion is presented to enable a person skilled in the art-9- QB\920171.00672\100158611.4Client Ref. UMN 2025-119to make and use embodiments of the invention. Various modifications to the illustrated embodiments will be readily apparent to those skilled in the art, and the generic principles herein can be applied to other embodiments and applications without departing from embodiments of the invention. Thus, embodiments of the invention are not intended to be limited to embodiments shown but are to be accorded the widest scope consistent with the principles and features disclosed herein. The following detailed description is to be read with reference to the figures, in which like elements in different figures have like reference numerals. The figures, which are not necessarily to scale, depict selected embodiments and are not intended to limit the scope of embodiments of the invention. Skilled artisans will recognize the examples provided herein have many useful alternatives and fall within the scope of embodiments of the invention.

[0051] Longitudinal activity tracking of aging individuals requires lightweight data structures and specialized configurations that allow a radar sensor to be implemented in large scale quantities across many geographic locations. The relationship between human movement patterns and cognitive status has been established with observational studies and accelerometer based wearable devices. However, this area of research has not successfully translated into a standard of care because of the lack of specially engineered devices and applications for real-world use. Because no baseline data is collected on movement patterns, no predictions can be made. Moreover, assessment of cognitive status and activities of daily living are typically required to be separate assessments. The systems and methods described herein provide the ability to monitor real-time fall events and longitudinal activity levels associated with cognitive status. Machine learning algorithms are combined with novel data processing methods and computationally efficient architecture to ingest, store, compute, and predict trends based on clinically relevant data.-10- QB\920171.00672\100158611.4Client Ref. UMN 2025-119

[0052] The present disclosure provides systems and methods for monitoring a health status of a patient in a contactless, noninvasive, and comprehensive way. The system employs radar sensors that can provide radar data that reflects the motion state of the patient and the surrounding environment. This data can be processed to monitor the health status of the patient. For example, the system can be used to detect a fall, longitudinally track the patient’s overall activity levels, estimate the patient’s cognitive status or fall risk through time, characterize a level of disease progression and so forth.

[0053] The described systems and methods allow for novel applications, such as real-time fall prediction and longitudinal activity tracking in multi-person scenarios without overhead visualization, room-dependent health indicators like urinary tract infection risk assessment via entry frequency tracking, and pediatric vital signs monitoring through blankets for prevention of sudden infant death syndrome (SIDS), all while preserving privacy and enabling scalable deployments in rural or facility-wide settings that are not achievable with standard configurations focused on broad-area surveillance.

[0054] The use of radar sensors advantageously maintains the privacy of patients, especially in comparison to camera-based surveillance. Moreover, the system functions noninvasively and does not require compliance of the patient. For example, the patient is not required to turn on, carry or wear, charge, or otherwise maintain the system. Instead, the system can be set up by caregivers a single time, then continuously and noninvasively monitor the patient, sending alerts to caregivers when appropriate.

[0055] The radar-based system is also advantageously scalable such that the sensors can be arranged in an array to meet the architectural needs of the environment. In this way, the number and physical placement of the sensors can be determined based on the architectural layout of the environment and the coverage needed for the desired -11- QB\920171.00672\100158611.4Client Ref. UMN 2025-119application. As one non-limiting example, the system can employ one sensor in each separate room (e.g., living room, bedroom, bathroom) of the patient’s living space or other environment (e.g., apartment within memory care facility, hospital room, nursing home residence, and so forth). As another non-limiting example, the system can employ several sensors in each separate room that have overlapping fields of view. This allows the system to capture motion from various perspectives, providing a more complete characterization of the movement through space (e.g., velocity in multiple dimensions).

[0056] The patient monitoring system can be provided in the form factor of a small, inconspicuous, and affordable ambient device. FIG. 1A provides a non-limiting example of a user device that may be arranged within an environment of interest. As a non-limiting example, the user device may have a housing with a rectangular prism shape and small dimensions (e.g., 2 inches x 2 inches x 0.5 inches). The device can also be colored or otherwise configured to blend into the surrounding environment. The small size of the device advantageously makes it convenient for use and inconspicuous in the user’s space. In this way, the user device may be referred to ‘miniaturized’. Moreover, the user device can be configured to be cost-effective and affordable so that its use can be scaled for applications such as hospitals, memory care facilities and so forth with large numbers of rooms or sensing environments.

[0057] In some implementations, the user device can be placed within a medical facility (e.g., hospital room) or a residence of a patient. For example, the sensor may be placed within an apartment in a continued care retirement community (e.g., independent living, assisted living, memory care) or nursing home. In some implementations, multiple sensors can be used in each residence. The system can also integrate monitoring of several patients. For example, one or multiple sensors can be placed in each apartment within a senior living community such that the care staff can continually monitor the -12- QB\920171.00672\100158611.4Client Ref. UMN 2025-119health status of each resident in a streamlined way.

[0058] As illustrated in FIG. IB, the system 100 includes at least one user device 102. The system may also include several user devices 102 arranged within an array. In this way, the system can be arranged based on the architectural layout of the environment in order to adequately characterize motion throughout the environment. As a non-limiting example, one user device 102 can be placed in each room of the residence (e.g., bathroom, bedroom, living room, kitchen). Sensor placement can be calibrated based on a blueprint of the layout to provide obstacle coverage. The compact size of the devices also enable flexible placement. For example, user devices 102 can be mounted on walls or ceilings, placed on tables or floors, incorporated into furniture or decorative pieces (e.g., frames, lamps), within outlets (e.g., similar to a nightlight), and so forth. In some implementations, sensors can be arranged to provide overlapping sensor fields, which enables tracking when one sensor view is occluded or allows for the combination of sensor data to increase the robustness of tracking. In this way, a patient may be monitored from multiple perspectives at one time and continuously monitored even when an obstacle is situated between the patient and a sensor. As non-limiting examples, 1-20 sensors can be placed in a single residence or apartment, 75-100 devices can be placed to cover a whole hospital or care center floor, 100-2000 devices may be used to cover a whole hospital or care center building, and 2,000-100,000 devices may be situation to cover a whole hospital or care center organization (e.g., across multiple locations throughout a hospital system).

[0059] Each user device 102 includes one or more radar sensors 104 and a processor 106. In some implementations, the radar sensors 104 can be configured to provide frequency-modulated (FM) radio waves. In some implementations, the radar sensors 104 may be a continuous wave (CW) radar sensor to reduce the overall power -13- QB\920171.00672\100158611.4Client Ref. UMN 2025-119requirements. As a non-limiting example, the radar sensors 104 may include a frequency modulated continuous wave (FMCW) radar. The radar sensors 104 may have a frequency range associated with a wavelength range. For example, the radar sensors 104 may be a millimeter wave (mmWave) sensor that has wavelengths on the order of 1-10 mm and high frequencies on the order of 30-300 GHz (e.g., 77 GHz).

[0060] The radar sensors 104 can be configured to emit radio waves that are reflected by the environment (e.g., walls, furniture, objects, people, and so forth), producing reflections. These reflections are measured by the radar sensor to generate reflection data, which may be referred to as radar data or raw radar data. The reflection data characterizes the position and velocity of the objects within the environment.

[0061] Each radar sensor 104 may include a phased array of transmitters and receivers that enable beamforming and steering. On the transmit side, these phased array arrangement can be used to direct outgoing radar signals. On the receive side, the array arrangement enables detection of reflection data that can be processed to provide angular resolution and point cloud generation. As a non-limiting, example, each radar sensor 104 may include multiple transmit (TX) antennas and receive (RX) antennas arranged in a two-dimensional array pattern to provide spatial resolution in azimuth and elevation, enabling the generation of three-dimensional point cloud data from the reflection signals. In some configurations, the sensor employs 2-3 TX channels and 4 RX channels in a MIMO arrangement, with frequency-modulated chirps for continuous wave operation.

[0062] In some implementations, the radar sensors 104 may be configured to provide frequency-modulated radar signals. For example, frequency-modulated continuous wave sensors can use frequency modulated signals, such as chirps, which provide a linear frequency ramp through time. This frequency modulation allows -14- QB\920171.00672\100158611.4Client Ref. UMN 2025-119continuous wave operation, which provides low power and high resolution in range and velocity. Frequency division or time-multiplexing may also be used across multiple TX antennas to avoid interference.

[0063] As will be described, the on-device processor 106 can be configured to control data measurement. For example, the processor 106 can configure the sensor’s radio waves, control emission of the waves, and control the sensor’s detection of the reflection data. In some implementations, the on-device processor 106 may also be configured to process the reflection data. As will be described, the on-device processor 106 can process the raw reflection data to reduce the data size, discarding extraneous data and maintaining clinically relevant data.

[0064] Each user device 102 can be in wired or wireless communication with an external processor 108, which may be a cloud-based processor, via the on-device processor 106. In some implementations, the external processor 108 can communicate with the user devices 102 to set user-defined settings. In some implementations, the external processor 108 can control (e.g., turn on or off) data acquisition and data transmission of the user device 102.

[0065] The processed and condensed data can be transmitted from each user device 102 to the external processor 108, where it can be stored, further analyzed, or communicated to a user or caregiver via the user system 110.

[0066] In some implementations, the external processor 108 can be configured to further analyze the aggregate motion data. For example, the external processor 108 can monitor the longitudinal data to identify health trends, as will be further described below. As another example, the external processor 108 can monitor the real-time data to identify a fall and create an alert.

[0067] In some implementations, the external processor 108 can be configured -15- QB\920171.00672\100158611.4Client Ref. UMN 2025-119with a cloud processing pipeline that includes a data streaming service. In this way, aggregated data can be ingested from the user devices 102 and routed to various processing paths. For example, one processing path may include real-time processing that can communicate real-time alerts via the user system 110 while a second processing path provides batch processing for longitudinal analysis. In this way, the external processor 108 may flexibly provide multiples channels for different process types. For example, a real-time channel may provide a time-series database for storing parsed data and serverless functions invoked on a schedule for data synchronization and alert generation while a batch channel provides stream processing applications that parse and compress data into archived formats stored in object storage buckets. In some implementations, this architecture can also include dedicated storage buckets for handling invalid events and state information, which may include rules for filtering and routing malformed or missing data.

[0068] The user system 110 may include a user alert protocol that alerts the user or caregiver of an adverse health status (e.g., fall, change in disease progression, fall risk, and so forth). In some implementations, the user can then be prompted to check on the patient to confirm the alert. The alert or notification system may also provide fail-alerts that indicate processing errors, data anomalies, or hardware failures (e.g., loss of power, obstructed view, and so forth). As a non-limiting example, alerts can be invoked directly from a time-series database using network requests.

[0069] The user system 110 can also provide the user with access to the patient data (e.g., longitudinal activity data, reports, fall alert history) to monitor the patient’s health trends. This data may be provided in the form of searchable dashboards that allow the user to query or visualize time-series across multiple sensors or facilities.

[0070] In some implementations, the user system 110 may be provided on a -16- QB\920171.00672\100158611.4Client Ref. UMN 2025-119caregiver’s personal device (e.g., desktop computer, pager system or smartwatch, smart phone or tablet, and so forth) or other user device. The user system 110 may include a display that provides real-time alerts and access to historical patient data. The user system 110 may also provide a summary report that encompasses the status of several patients within a care system (e.g., all patients within a wing of a hospital or at-risk patients within a senior living community).

[0071] The processing architecture provided by the system 100 can be encrypted to protect patient privacy. For example, the cloud processing pipeline may include encryption for state files to protect embedded sensor certificates. The cloud processing pipeline may also support automation for sensor provisioning at scale to eliminate the need for manual certificate installation. The cloud processing pipeline may also integrate authentication services that provide secure access to visualization dashboards through the user system 110.

[0072] The methods described herein additionally provide a processing architecture that is computationally efficient and tailored to provide high quality and medically relevant data. In this way, the methods provide a way to distill large amounts of raw radar data into relevant activity data, reducing the data size by 80-90% of traditional radar data sets. This makes it computationally feasible to monitor or track health status with a user-friendly and affordable system. As non-limiting examples, the system can be used in real time to detect falls, used longitudinally to monitor progression of disease or cognitive health, or a combination thereof.

[0073] As will be described, the processing architecture includes aggregating the radar data to reduce computational burden and increase data privacy. The pipeline includes receiving radar reflection data and generating point cloud data from the radar reflections. The raw point cloud data can include individual 3D coordinate (e.g., x, y, and -17- QB\920171.00672\100158611.4Client Ref. UMN 2025-119z), velocity, and signal strength for each measured data point. This raw point cloud data is then processed to extract height metrics (e.g., a range of likely z-values for each detected target), label data with a timestamp, and summarize activity level through time. The data is aggregated and summarized using algorithmic steps, which may include clustering points using density-based methods (e.g., identifying body-related clusters from human movements), computing statistical aggregates on z-coordinate data to provide height-focused insights, and serializing the reduced dataset into a lightweight computational structure (e.g., (JavaScript object notation, JSON) to provide transmission efficiency. Omitting the granular spatial details and focusing on aggregated height data also improves patient privacy by preventing pose reconstruction from saved data.

[0074] This process advantageously provides rapid, low-bandwidth analysis of time-series changes (e.g., head height drops for fall detection) without the computational overhead of full datasets, enabling real-time and longitudinal data tracking for health monitoring applications. Moreover, the reduced computational needs facilitate low-bandwidth internet of things (loT) integration, which may be used in rural or facilitywide settings.

[0075] An example process 200 for monitoring health status of a patient is outlined in FIG. 2.

[0076] The process 200 includes accessing raw radar or reflection data, as indicated in process block 202. In some implementations, accessing raw radar data may include retrieving the data from a memory. In some implementations, accessing raw radar data may include using a processor to control one or more radar sensors to generate radar reflections that contain information about the environment surrounding the radar sensor(s). In some implementations, accessing the raw radar data may include accessing raw data from multiple sensors arranged in an array or controlling multiple -18- QB\920171.00672\100158611.4Client Ref. UMN 2025-119sensors in an array to measure radar data.

[0077] In some implementations, accessing the raw radar data may include measuring the data after configuring the radar sensors with operational parameters that are tuned to provide high quality and medically relevant information. The sensor configuration can be set to provide precise, low-height detection in indoor environments, which enables accurate capture of subtle motions (e.g., slow falls or sedentary behaviors that are associated with AD / ADRD).

[0078] The sensors can be configured to measure data over a fixed time period or frame. In some implementations, the frame rate can be set between 10-30 Hz, 1-100 Hz, or a rate sufficient to capture human-scale motion.

[0079] The sensor may be configured with customized frequency pattern. For example, the radar sensor may generate a frequency-modulated radio wave.. In some implementations, the frequency-modulated radio wave may be transmitted as a continuous waveform (e.g., frequency-modulated continuous wave, or FMCW) or generated as a pulsed waveform (e.g., linear frequency-modulated or chirped pulse).

[0080] In some implementations, the frequency modulation is defined as a chirp pattern. For example, the radar sensor can be configured with a chirp that sweeps the carrier frequency (e.g., linearly) over a range or bandwidth of frequencies. This chirp pattern can be tuned to monitor human-scale motion in indoor environments with high accuracy and sensitivity. For example, the bandwidth of the chirp frequency modulation can be set based on the desired resolution to adequately characterize the environment. The minimum or start frequency can also be tuned to shift the operational frequency band upward or downward. In this way, the frequency band can be adjusted based on the desired features and tradeoffs of the system. For example, shifting the frequency can affect signal penetration and attenuation, resolution and accuracy, regulatory and -19- QB\920171.00672\100158611.4Client Ref. UMN 2025-119interference compliance, and other overall system performance tradeoffs (e.g., hardware design and antenna efficiency) As a non-limiting example, the chirp radio frequency wave may have a range of 30 to 300 GHz, or more specifically a range of 60-64 GHz, which is an unlicensed industrial, scientific and medical (ISM) band configured for short-range and high-sensitivity indoor use. The chirp time or repetition time can also be tuned based on the range of velocities of interest. As a non-limiting example, the chirp repetition time may be set between 20 and 200 ps. In this way, the parameters of the chirp frequency modulation pattern (e.g., frequency range, frequency slope or ramp, and chirp duration) can be set to tune the resolution of the raw echo data, the point cloud accuracy, and the accuracy of the velocity measurements.

[0081] The radar sensor can also be configured with detection layer tuning to provide enhanced range and angle resolution. In some implementation, the detection layer can be tuned with dynamic constant false alarm rate (CFAR). In some implementations the detection layer may employ constant CFAR. The angle configuration of the detection layer can be set to specify the number of angle bins (e.g., 32 to 256 for azimuth and elevation FFT processing) and enable or disable elevation estimation, depending on the desired field of view and resolution. This impacts angular resolution (e.g., 1-5° accuracy), allowing the radar to distinguish multiple targets in cluttered indoor spaces, improve 3D point cloud quality for precise height tracking in fall detection, precisely track subtle movement, and reduce false alarms from environmental noise. Such settings can work to filter clutter from the radar data to produce cleaner point clouds, which enables precise z-coordinate extraction without excess noise that bloats the output.

[0082] The radar sensor can also be configured with customized tracking layer settings. For example, the tracking layer can employ ground-level sensor position (e.g., 0°-20- QB\920171.00672\100158611.4Client Ref. UMN 2025-119elevation compared to the standard elevation of elevation of 15°) to provide accurate height estimation. The ground-level sensor position is a configurable parameter that defines the assumed elevation angle or tilt of the sensor relative to the ground plane. It can be used to calibrate the coordinate system and improve height accuracy in object tracking. This parameter can also be adjusted based on the physical location of the device itself (e.g., sitting on the floor, mounted on a wall or ceiling). For example, the groundlevel sensor position can be set with a downward tilt if the device is mounted on the ceiling.

[0083] The tracking layer can also be configured with reduced state transitions to provide quicker motion capture. In some implementations, the state transition times may be set to between 3-10 units or frames, depending on the specific threshold (e.g., detection-to-active or active -to -free transitions). In tracking, the tracks (e.g., that represent a human target) evolve through states, such as free (e.g., unallocated), detect (e.g., tentative detection), and active (e.g., confirmed and tracked). The state transition times refer to configurable thresholds that specify the number of consecutive "hits” that define detections or "misses" that define no detections in frames required before a track changes state. Reducing these (e.g., from defaults like 20 to 6 units) means fewer frames are needed for transitions, allowing the system to more rapidly initialize, confirm, or deallocate tracks. Physically, this equates to reduced latency in responding to real-world motion. As a non-limiting example, at a typical frame rate of 10-30 Hz (100-33 ms per frame), 6 units translates to 200-600 ms of observation time before a state change. This enables quicker capture of dynamic events like sudden falls or activity shifts in the described health monitoring system, improving real-time accuracy without excessive false positives from noise. .

[0084] The tracking layer may be configured with tuned gating parameters to -21- QB\920171.00672\100158611.4Client Ref. UMN 2025-119provide efficient data association in multi-target (e.g., Kalman-based) tracking, rejecting irrelevant points (e.g., static objects or noise) while maintaining track continuity for human motion. The tracking layer may also use lower allocation thresholds to provide small-object sensitivity. As a non-limiting example, the velocity allocation threshold can be set between 0.1 to 0.05 m / s, or more specifically to 0.05 m / s. The acceleration limits and boundary boxes of the tracking layer can be set based on human-scale acceleration. The boundary boxes can be adjusted to define the active spatial region for tracking within the sensor's field of view, such as setting minimum and maximum coordinates in x, y, and z dimensions to match the monitored environment (e.g., room boundaries or excluding static areas like walls). This confines processing to relevant areas, reducing computational overhead from extraneous detections and improving accuracy for humanscale targets in indoor settings like patient rooms. As non-limiting examples, the x / y boundaries may be set to ±5-10 meters (radial from sensor), and the z boundaries may be set from 0-3 meters (e.g., ground to ceiling height). Calibration tests can be used during setup to tun the bounding box based on the deployment space. Boundaries can also be set based on velocities and accelerations. As a non-limiting example, the maximum acceleration limit may be set to 1 m / s2.

[0085] In some implementations, the tracking layer can employ advanced tracking modes advanced tracking modes, such as group tracking for multi-object scenarios using extended Kalman filters (EKF), people tracking optimized for human kinematics and presence detection, or joint probabilistic data association (JPDA) for associating detections in cluttered environments. These modes enhance accuracy in applications like fall detection by improving multi-person differentiation and reducing false tracks in indoor settings. The customized configuration of the tracking layer provides refined tracking data that focuses on human kinematics, prioritizing fall-relevant heights and -22- QB\920171.00672\100158611.4Client Ref. UMN 2025-119providing human activity tracking.

[0086] The raw radar data are pre-processed in process block 204. In some implementations, all or part of the pre-processing the raw data can be performed locally on the sensor’s processor based on the configuration of the sensor as previously described. In some implementations, all or part of the pre-processing can be performed on an external host processor located within the user device. Pre-processing the data locally on the user device advantageously reduces data transmission requirements (e.g., to a cloud-based processor).

[0087] Pre-processing the raw data includes analog-to-digital conversion and transforming the data using Fourier transforms. A range fast Fourier transform (FFT) can be used to determine the range (e.g., distance between the sensor to the surface of a target) and azimuth or elevation of each datapoint. A Doppler FFT can be used to estimate the velocity for each datapoint. Pre-processing may also include beamforming analysis to determine the three-dimensional position (e.g., x, y, z) of each datapoint. In this way, the pre-processed data may include 3D point cloud coordinates, a velocity, and a signal strength measurement for each measured datapoint.

[0088] In some implementations, the sensor’s processor can provide the 3D point cloud data as a raw binary output (e.g., in TLV format) to an external host processor, which may be located within the user device. As non-limiting examples, the sensor can transmit the data to the host processor using a Universal Asynchronous Receiver / Transmitter (UART) protocol, serial peripheral interface (SPI) protocol, or low-voltage differential signaling (LVDS) for raw data capture. The processor can then parse the data to store it as a structured dictionary that contains the full array of detected points with attributes that may include the 3D coordinates, velocities, and signal strengths. This data characterizes the position and velocity associated with each measured datapoint and -23- QB\920171.00672\100158611.4Client Ref. UMN 2025-119may be referred to as motion state data.

[0089] The motion state data is processed in process block 206 to discard irrelevant data that is not associated with motion of a human target. Process block 206 can include filtering and clustering the data to identify relevant movement patterns and to filter data that do not correspond to human movement.

[0090] Raw point clouds include extraneous points from static objects or nonhuman motions. Filtering can be applied to remove environmental clutter, such as reflections from walls, furniture, or stationary objects, allowing the system to focus on dynamic human movements like walking or falling. In some implementations, filtering can be applied iteratively.

[0091] In some implementations, filtering can be applied based on signal strength or signal to noise ratio (SNR), velocities, consistencies of tracked velocities or paths through time, or a combination thereof. As a non-limiting example, points with low SNR (< 10 dB) can be discarded. As another non-limiting example, points with static velocities or a velocity below a tunable threshold (e.g., < 0.1 m / s) can be discarded. As another nonlimiting example this threshold can be set between 0.05-0.2 m / s to capture subtle motions (e.g., breathing or slow shuffling in elderly patients) while eliminating noise. In some implementations, thresholding can be implemented post-Doppler FFT in the point cloud generation phase. In some implementations, other filtering methods can be used to discard to suppress stationary data to enhance overall quality and computational efficiency. As non-limiting examples, these may include SNR filtering, a Kalman filter for consistency checking, clustering and point clustering filters, boundary boxes and gating, or CFAR thresholding.

[0092] Clustering algorithms are applied to the point cloud data to associate points with individual objects and motion tracks. A motion track or track describes the motion -24- QB\920171.00672\100158611.4Client Ref. UMN 2025-119pattern of an identified object or cluster through time. As a non-limiting example, clustering algorithms can be configured to perform density-based groupings of point cloud data. In some implementations, the clustering algorithms may be applied based on x, y, and z coordinates of the data, velocities of the data, or a combination thereof.

[0093] Clustering algorithms can be used to distinguish body-related clusters from environmental clutter. Z-coordinates are iteratively scanned to isolate height-relevant subsets. In some implementations, the human detection can be performed by applying a trained machine learning algorithm (e.g., convolutional neural network, CNN) that is trained to use radar-specific features. To classify clusters as human if they exhibit biomechanical traits (e.g., elliptical torso shapes, limb velocities of 0.1-2 m / s, and so forth). As a non-limiting example, the machine learning algorithm (e.g., CNN) can be trained to classify human clusters based on the micro-Doppler signature of the data. This improves detection accuracy, especially in a multi-person environment.

[0094] Each cluster can be characterized by a grouping of point cloud data and may be described by a center (e.g., mean or weighted mean of the position coordinates) and summarized velocity (e.g., mean, weighted mean, velocity of a center point). Each identified cluster can be assigned a track identification number so that the movement pattern of each individual is tracked through frames. In this way, the system can support tracking in multi-person scenarios and can be applied in shared spaces (e.g., memory care facilities).

[0095] In some implementations, filtering and clustering can be employed iteratively in process block 206. As a non-limiting example, individual datapoints can be filtered based on SNR, followed by clustering point cloud data, followed by filtering of static clusters and non-human-like motion tracks. In this way, filtering can be applied to remove datapoints associated with static objects or non-human motions.-25- QB\920171.00672\100158611.4Client Ref. UMN 2025-119

[0096] As a non-limiting example, individual datapoints can be filtered based on SNR, followed by clustering point cloud data, followed by filtering of static clusters and non-human motion tracks. For example, this filtering process may include several iterative steps. First, point-level filtering is applied based on SNR and velocity. Raw point clouds from the radar (after Range FFT, Doppler FFT, and beamforming) include attributes like 3D position (x, y, z), radial velocity (from Doppler), and SNR for each detected point. Points with low SNR (e.g., <10 dB) are filtered out using a simple threshold, as these often represent noise or weak reflections from distant / static clutter. Simultaneously or next, a velocity threshold (e.g., discard if absolute velocity <0.1 m / s or exactly 0 m / s) is applied, since stationary objects produce zero Doppler shift in the Range-Doppler map. The filtered point cloud can then be clustered by applying densitybased algorithms (e.g., density-based spatial clustering of applications with noise) to group nearby points into clusters, using parameters such as a distance threshold or epsilon (e.g., 0.2-0.5 m) and minimum samples (e.g., 3-5 points). Clustering considers spatial coordinates (x,y, z) and optionally velocity for better separation. Outliers (isolated points) are discarded as noise. Additional filtering can be applied after clustering. For each cluster, summary statistics (e.g., mean velocity, centroid position, size / shape via bounding box or eigenvalue analysis) are calculated. Static clusters (mean velocity ~0 m / s across frames) or those with non-human traits that are too small / large, inconsistent velocity paths, or lacking biomechanical patterns like limb swings) are discarded. ML models (e.g., CNN trained on micro-Doppler signatures, time-frequency spectrograms from STFT on velocity data) can be used to classify clusters as human if they show traits like elliptical torso shapes or limb velocities of 0.1-2 m / s. Kalman filters can further check trajectory consistency, rejecting erratic or stationary track

[0097] In some implementations, data clustering can be applied to identify a body -26- QB\920171.00672\100158611.4Client Ref. UMN 2025-119part or anatomical region of interest. Such anatomic-specific clustering can be performed using machine learning algorithms based on typical anatomical characteristics. For example, the machine learning algorithm can leverage cluster shape (e.g., ellipsoidal for torso vs. spherical for head), temporal movement patterns (e.g., gait cycles or limb swings via trajectory analysis), velocities (e.g., higher for arms / legs than torso), micro-Doppler signatures (e.g., frequency modulations from periodic motions like walking), and so forth.). In some implementations, this enables precise identification of body parts (e.g., head, torso, limbs) for applications like fall detection, where focusing on the head's height drop improves accuracy over whole-body analysis. In some implementations, data representing clusters associated with the limbs can be discarded. As another example, machine learning algorithms can be applied to isolate the cluster data associated with each individual’s head, chest, or torso.

[0098] As non-limiting examples, the clustering can be performed using machine learning algorithms, such as convolutional neural networks (CNNs) for classifying clusters based on spatial features, recurrent models (e.g., long short-term memory, LSTMs) for temporal patterns, or point cloud-specific networks (e.g., PointNet or variants) that process unstructured 3D data directly. In some implementations, densitybased clustering (e.g., DBSCAN) precedes machine learning to group points, followed by feature extraction (e.g., eigenvalues for shape compactness or velocity histograms). Training datasets may include labeled radar point clouds from simulated or real human activities (e.g., walking, falling), augmented with noise to handle indoor clutter.

[0099] In some implementations, the clustered motion state data can be filtered based on velocity thresholds that isolate dynamic movements indicative of human activity. In this way, process block 206 can reduce the data set by discarding data associated with stationary objects or stationary people within the environment. It also -27- QB\920171.00672\100158611.4Client Ref. UMN 2025-119groups the data to track each individual through frames, labeling them with a tracking identification. Thus, the output of process block 206 can include tracked motion state data that characterizes a time course of clustered point cloud data associated with human-scale motion for each individual in the environment. This tracked motion state data may also be associated with velocity data for each point. In some implementations, the tracked motion state data may also include corresponding signal strength measurements.

[0100] The tracked motion state data can be aggregated in process block 208 to further reduce the data size and focus the dataset to extract the relevant information. The extracted data provides a time course of aggregate motion data that may include aggregate activity data, summarized height metrics, summarized position metrics, a summarized velocity metrics, summarized acceleration metrics, a summarized derivative metrics, or a combination thereof. The aggregate motion data may further include time stamps or a record of the room or particular sensor used to measure the data to provide context for further processing.

[0101] This procedure reduces the dataset by discarding extraneous attributes, achieving compression by focusing on biomechanically relevant summaries and describing the tracked motion state based on the aggregated cluster rather than each point within the cluster. For example, data can be reduced to describe head height for falls, body center velocity to identify motion patterns, or activity levels for longitudinal tracking. Discarding irrelevant data provides data reduction without losing important health monitoring insights. This facilitates computationally efficient transmission of data (e.g., to a cloud-based processor or memory). The data reduction also reduces data storage space required for longitudinal data tracking, which is especially useful when tracking data for many patients over long periods of time. The reduced dataset also makes -28- QB\920171.00672\100158611.4Client Ref. UMN 2025-119it easier to apply machine-learning methods that typically require large patient cohorts, as it mitigates the computational burden associated with training models on massive datasets

[0102] As a non-limiting example, the aggregate motion data include a summarized height metric that describes a z-coordinate of the tracked motion state data. For each identified track (e.g., each tracking identification associated with an individual), statistical aggregation is performed on the z-coordinate values from the clustered point cloud data. For example, sub-clusters with the highest z-coordinates (e.g., top 10-20% of points by elevation) can be identified. A centroid can be computed (e.g., mean x, y, and z position or maximum z as a proxy for head height). Machine learning algorithms (e.g., CNN) can also be applied to label the cluster based on shape (e.g., compact and spherical) or velocity e.g., low for head vs. limbs).

[0103] In this way, a height metric summary is computed for each identified track, producing a summarized height metric through time. As a non-limiting example, the z-coordinate values or height of each point within the cluster can be averaged together to determine a central height of the cluster, which may be referred to as a centroid. As another non-limiting example, statistical methods can be used to determine a range (e.g., middle 50%, minimum and maximum) of likely height values. As another non-limiting example, statistical methods can be used to determine a data distribution and summarize the height metric based on a standard deviation or other statistically likely range or value.

[0104] As another non-limiting example, the aggregate motion data can describe the motion state of the body’s center or centroid. For example, all points within the human cluster can be averaged together, which may include SNR-based weighting for robustness, to find the geometric center. As another example, principal component analysis (PCS) can be used on eigenvalues to estimate a torso centroid as the most stable -29- QB\920171.00672\100158611.4Client Ref. UMN 2025-119or central sub-cluster. This can serve as a reference for overall position or velocity tracking, especially in a multi-person scenario.

[0105] In some implementations, the aggregate motion data include a summarized position metric that describe the position (x, y, and z) of the tracked motion state data through time. As similarly described with respect to the summarized height metric, each tracked human motion can be described by a centroid position of a cluster of interest (e.g., head, torso, body average) through time. For example, the summarized position metric may describe an x, y, and z position of a center of a patient’s head through time or a center of a patient’s torso through time. Maintaining x and y coordinates of the summarized position data can optionally provide greater flexibility in health monitoring with trading off a small increase in data size.

[0106] In some implementations, the aggregate motion data can include a summarized derivative metric that describes a temporal derivative of position of the tracked motion state data in time. As non-limiting examples, this derivative may describe a velocity, an acceleration, or a higher-order temporal derivative. Such derivative data may be determined based on a height only, a cartesian position (e.g., in x, y, and z), or based on another axis of interest. This may include taking a first-order or higher order temporal derivative of a position (e.g., height; x, y, and z; or combination thereof) and tracking the derivative through time. Such data can be used to detect sudden movements, for example, that characterize overall motion patterns or other features of motion (e.g., gait).

[0107] In some implementations, the aggregate motion data may also include a tracking identification to identify what motion track is associated with the corresponding aggregate motion data (e.g., summarized height data, summarized position data, summarized velocity data, summarized acceleration data, summarized derivative data,-30- QB\920171.00672\100158611.4Client Ref. UMN 2025-119aggregate activity data). In this way, height data for multiple individuals can be characterized and stored with individual tracking identifications.

[0108] Process block 208 may include discarding data that is not relevant to the health status monitoring application of interest. For example, the summarized height metric (e.g., z-coordinate) can be stored through time while discarding lateral (e.g., x- and y-coordinates) after aggregation to reduce the overall data size. In some implementations, the velocity data (e.g., the Doppler velocity) and signal strength associated with each datapoint can also be discarded.

[0109] Discarding x- and y-coordinate data advantageously reduces the overall data size and provides a higher level of data privacy, preventing the reconstruction of detailed posture data or spatial trajectories. This provides stronger privacy protection than typical radar systems, which often retain or transmit denser point clouds for machine learning-based classification (e.g., feeding raw / sparse points into CNNs or autoencoders for anomaly detection). By focusing exclusively on vertical (e.g., z-height) aggregates tied to track identifications, the method enables effective time-series analysis for health indicators (e.g., sudden min / max height drops signaling falls) while minimizing reconstructible personal data. This makes the process well-suited for in-home elderly monitoring without consent risks associated with pose-estimatable data.

[0110] Process block 208 may also include generating aggregate activity data. As the motion state data (e.g., as described with respect to process block 206) was previously filtered based on SNR thresholds to exclude artifacts, clustered to track motion patterns, and filtered to identify data related to human motion, the number of datapoints left within the clustered human data can serve as a proxy for movement intensity. For example, more vigorous or complex activities (e.g., walking or gesturing) generate denser point cloud data and clustered human data due to increased scattering of radar -31- QB\920171.00672\100158611.4Client Ref. UMN 2025-119reflections from body parts in motion, while sedentary states (e.g., sitting or sleeping) produce fewer points. Thus, as one non-limiting example, the number of valid points in the clustered human data can be summed together for each frame (e.g., 10-30 Hz) or other relevant time period to determine an aggregate activity level. This characterizes an activity level measured through time using a single metric. Such metric may be akin to actigraphy from a wearable device but advantageously determined using a contactless and scalable system. In some implementations, the aggregate activity level may be determined based on a normalized or weighted point count. For example, the sum can be weighted based on SNR, velocity magnitude, or cluster size (e.g., size of bounding box volume to approximate radar cross-section variability). In multi-person scenarios, the points can be summed per tracked identification to avoid conflating activities from multiple people. As another example, the points can be counted over a window using means or integrals that smooth noise and capture sustained activity levels.

[0111] In some implementations, extracting aggregate motion data may include combining data from multiple sensors. For example, if an individual moves out of view from one sensor into another, the time course data can reflect motion data measured from the first sensor, followed by that measured by the second sensor. In this way, the motion pattern can be continually characterized to fully grasp the individual’s activity level throughout their space.

[0112] In some implementations, the aggregate activity data can be normalized or calibrated to a score. In this way, the total number of points measured, which represent an intensity of activity, can be mapped to a clinically useful or otherwise intuitive scale. For example, the total number of points can be normalized based on a baseline activity level.

[0113] In some implementations, the aggregate motion data may also include -32- QB\920171.00672\100158611.4Client Ref. UMN 2025-119associated temporal information. For example, the data may be labeled with corresponding time stamps that indicate the time at which the data was measured. As a non-limiting example, a Unix timestamp can be generated from the system clock at the moment of aggregation. In other implementations, the timestamp can be generated based on the start, middle, or end time of the corresponding measurement frame. The timestamp can be converted to a human-readable form, appending these timestamps to the summary structure to enable time-series correlations. This ensures chronological integrity and real-world context (e.g., low activity levels during night-time hours) for future longitudinal tracking or analysis. Recording the measurement time may also be helpful for synchronizing radar data with clinical assessments (e.g., Montreal Cognitive Assessment, MoCA scores) without the overhead of embedding full timestamps per measured point.

[0114] In some implementations, the aggregate motion data can also be labeled based on the particular user device or sensor used to measure the data. For example, the data can be labeled based on a sensor identification or a location (e.g., GPS, room location, patient residence, and so forth) of the sensor. Such label can provide context for the data processing (e.g., understanding activity levels in the bathroom vs. living room).

[0115] The aggregate motion data can be organized and stored in a lightweight data structure for convenient transmission, storage, or further processing. As a nonlimiting example, the aggregate motion data can be serialized to a custom JSON structure. A JSON dictionary can be constructed, including only the relevant or desired elements. For example, the JSON dictionary may include the frame number (e.g., determined from the header), the summarized height metric, the timestamp or current time string, and the aggregate activity data. Such data can be provided as an array, with each element representing a frame through time. In some implementations, serialization libraries can -33- QB\920171.00672\100158611.4Client Ref. UMN 2025-119be used to output a compact file or stream. The full point cloud data advantageously does not need to be saved, providing a large reduction in data volume (e.g., 80-90% reduction compared to the full point cloud data).

[0116] In some implementations, process blocks 202-208 can be performed locally on the user device. In this way the data are processed and summarized using lightweight algorithmic steps (e.g., clustering, statistical min / max on z-arrays, point counting with SNR filtering) to provide the relevant data in a compact data structure (e.g., JSON with {frameNumber, HeightData: [{trackID, maxZ, minZ}], timestamp, pointsDetected) for each frame). This compact structure is suitable for low-bandwidth upload to cloud-based machine learning models. Typical systems typically transmit or process full point clouds locally for direct classification, increasing power / compute demands on edge devices.

[0117] Process block 210 includes processing the aggregate motion data to determine a health status of a patient. The data can be processed in several different ways depending on the desired applications. For example, the data can be processed in realtime to detect urgent health changes and processed longitudinally to detect slower health changes that can guide treatment and care. In this way, the system and process advantageously provide a multi-path architecture that enables real-time monitoring and alerts along with longitudinal trend analysis.

[0118] For example, a dual-channel architecture can be used to provide transmission of aggregated data where one channel handles real-time alerts, and one channel handles longitudinal storage and analysis. As a non-limiting example, data can be divided into two paths, including a real-time path for urgent notifications (e.g., fall events validated with human-in-the-loop alert and algorithm refinement) and a longitudinal path for analytics. Secure message buses (e.g., Message Queuing Telemetry Transport,-34- QB\920171.00672\100158611.4Client Ref. UMN 2025-119MQTT) can be used for transmission while time-series databases can be used for storage, thereby facilitating predictive modeling correlations with clinical tools (e.g., MoCA). This dual-channel design, combined with algorithmic fusion incorporating time alignment and patient decision logic, allows for organization-wide scalability across health facilities, addressing gaps in previously described systems by integrating radar-derived metrics like activity trends generated from point clouds.

[0119] Process block 210 may include multi-sensor fusion, which may be applied to combine data from multiple sensors for a single patient (e.g., combining sensors located in a patient’s bathroom, living room, and bedroom) or applied to organize data across patients for a given facility. As a non-limiting example, combining the multi-sensor data may include combining non-redundant data from two sensors measuring overlapping regions in space. For example, when SNR is low from one sensor, a second sensor can be used to supplement that data. Similarly, when a view from one sensor is obstructed, a data from a second sensor can be used. In this way, multiple sensors can be position throughout a space so that if one has an obstructed view, others will continue to monitor the space, enabling full coverage and uninterrupted monitoring. As another example, when two sensors see the same space, data can be combined based on averaging, SNR-weighted averaging, or otherwise combined to provide more robust tracking. Combining data for each patient can provide more robust monitoring of their health. Combining data across a healthcare system (e.g., a senior living home) provides a convenient and efficient way to monitor many patients simultaneously.

[0120] As still another example, the multi-sensor data can be combined from sensors with overlapping fields of view. In this way, the system can advantageously employ several low-cost sensors deployed throughout the living space with intentionally overlapping fields of view. This multi-sensor configuration not only mitigates occlusions -35- QB\920171.00672\100158611.4Client Ref. UMN 2025-119and provides redundant coverage from diverse vantage points but also enables the capture of complementary and partially orthogonal data streams from the same subject. Data acquired from one sensor (e.g., due to its position, angle, or partial occlusion) differs subtly, or sometimes significantly, from data acquired simultaneously from another sensor viewing the same activity. For example, each sensor may measure velocity through a different dimension. By fusing these multi-view temporal sequences, the system extracts enhanced features unavailable from any single sensor, such as improved activity tracking, velocity or acceleration in multiple dimensions, micro-movements, or higher-order derivatives over time. Scaling the number of low-cost sensors generates highdimensional and temporally rich data that can be used with various machine learning algorithms to characterize a wide range of activity patterns.

[0121] Process block 210 may include transmitting the aggregate motion data to a memory that is configured to store the longitudinal data through time. In this way, longterm patterns in activity can be analyzed and monitored to determine health changes or to train algorithms to detect or characterize health statuses.

[0122] Process block 210 may include applying a trained algorithm, such as a machine learning algorithm, to identify a wide variety of health conditions or health statuses. For example, longitudinal tracking can be used for applications such as assessing a level of cognitive impairment, chronic disease (AD / ADRD, dementia, Parkinson’s) progression or risk, fall risk, mobility status, sleep quality, general activity levels, caloric expenditure, sedentary behavior, time in bathroom, and so forth. As another example, the real-time data can be analyzed to identify patient behaviors (e.g., sitting, standing, walking, sleeping, and so forth) or events (e.g., falls). As yet another example, real-time data can be used to create an alert when a patient is identified as having low activity levels (e.g., sedentary behaviors determined by a seated head height) during daytime hours for -36- QB\920171.00672\100158611.4Client Ref. UMN 2025-119a prolonged period of time.

[0123] Identifying a health status in process block 210 may rely on the summarized height metric measured through time, aggregate activity data measured through time, or combination thereof. In some implementations, the time of day associated with the aggregate motion data or sensor room may further influence the determination of the health status.

[0124] In some implementations, longitudinal data can be correlated with various metrics of different health conditions. As a non-limiting example, the activity levels (e.g., aggregate activity data) can be correlated through time with clinical metrics such as MoCA scores or other cognitive health scores, John’s Hopkins Fall Risk Assessment or other fall risk score, disease stage, or other measures of physical or cognitive health.

[0125] In some implementations, the longitudinal activity levels can be correlated with caloric expenditure according to a patient’s activity patterns through time. The activity level time courses can also be correlated to Metabolic Equivalent of Task (MET) values using a biomechanical model. For example, the model may be based on the Compendium of Physical Activities. Thresholds can be set for groups or individuals. As non-limiting examples, the thresholds for sedentary behavior can be set as <0.5 m / s or 1-1.5 METs.

[0126] The longitudinal data can advantageously be monitored and analyzed through time in order to detect changes for a particular patient that may indicate a change in health. For example, the trained algorithms can identify a significant or clinical change in a patient’s activity level, cognitive level, MoCA score, mobility status, fall risk, sleep patterns, caloric expenditure, and so forth.

[0127] Such longitudinal data tracking can advantageously be analyzed within context (e.g., time of day or physical location). For example, context-specific tracking can -37- QB\920171.00672\100158611.4Client Ref. UMN 2025-119be applied to identify sundowning behaviors characterized by activity changes near dusk. As another example, changes in bathroom use can be identified (e.g., number of bathroom entries, time in bathroom) can be identified, which may indicate the presence of a urinary tract infection or other medical condition. Similarly, the data can be analyzed to characterize time spent in various locations (e.g., in living room, near television, in bed) to identify patterns or changes in how the individual spends their time.

[0128] Process block 210 may include identifying a fall of the patient, which can advantageously be performed in real time (e.g., with <1-, <5-, or <10-minute delay time) to provide real-time alerts to caregivers. In some implementations, fall detection can be determined based on a time-series height analysis of the summarized height metric, which may be performed by a trained machine learning algorithm. For example, the fall detection may include monitoring the height data for rapid drops over short periods of time, low head positions for extended periods of time, or a combination thereof. As a nonlimiting example, summarized height data can be analyzed to detect rapid head height changes (e.g., decrease by 50-90%) over 1-30 seconds or a head position below 1-3 feet for more than 10-120 seconds. In this way, medial-lateral, anterior-posterior, collapse, and slow falls (e.g., leaning against furniture or a wall throughout the fall) can all be detected. The fall thresholds can also be determined based on an individual’s historical data. In some implementations, a machine learning algorithm (e.g., RNN) can be trained to detect a fall. The machine learning algorithm may be trained or fine-tuned on patientspecific data to tailor the algorithm based on the individual’s movement patterns. Moreover, fall detection can include human in the loop confirmation of falls, which can be input into the algorithm to continue to refine its accuracy.

[0129] In some implementations, longitudinal or real-time data (e.g., height metric data, activity data, or a combination thereof) can be analyzed to identify patient -38- QB\920171.00672\100158611.4Client Ref. UMN 2025-119behaviors. For example, a pattern of head height through time can be analyzed using a machine learning algorithm to determine whether the patient is sitting, sleeping, walking, or on the floor. The behavior recognition may also depend on contextual factors, such as the corresponding room or time of day. In some implementations, behavior classification can be performed using a k-nearest neighbors algorithm. As a non-limiting example, the following thresholds can be used: sleeping identified for heights 0.5-1 m, walking identified for height >1.3 m with high levels of activity that indicate velocity, a patient on the floor is identified for heights <0.5 m. Sleeping and sitting thresholds can also be set for an individual based on their space (e.g., the distance from their pillow to the floor), their height, or a combination thereof (e.g., their typical height in their recliner chair).

[0130] In some implementations, the described systems and methods may further be applied in the context of pediatric monitoring. In this application, clustering may be applied to characterize chest movement of the patient. The motion state data can be processed to generate micro-Doppler analysis data that characterize a micro-Doppler signature of the motion state data. This micro-Doppler signature can be analyzed to determine vital signs of a patient (e.g., an infant), such as a pulse, heart rate, respiratory rate, or respiratory state. The pulse and respiratory rate can be tracked and monitored through time to determine a risk of sudden infant death syndrome (SIDS) or to alert a caregiver of an adverse change in the patient’s vital signs. Such technology can advantageously be applied to monitor at-risk infants, for example in bridge care after being discharged from the neonatal intensive care unit (NICU). Moreover, such monitoring can be robustly applied in flexible environments (e.g., when the patient is wearing blankets or various types of clothing, when the patient is situated in various positions or locations, and so forth) without requiring contact with the patient. In this way, the described systems and processes can be applied to reduce SIDS in pediatric -39- QB\920171.00672\100158611.4Client Ref. UMN 2025-119populations. Alerts can be integrated with infant monitors (e.g., video monitors).

[0131] A report or alert can be generated in process block 212 based on the determined health status. Reports may include summaries of health statuses over time for each patient or may be queried to provide information in varying levels of details (e.g., visualize aggregate motion data through time with associated health status determinations). In some implementations, the reports can aggregate important patient data for a large group of patients (e.g., all residents in a senior living community) to conveniently distill relevant information for caregivers. For example, a dynamic report can provide a status report that lists the status of each patient. In some implementations, an alert can be provided, which may include an alarm. Such alert can prompt a caregiver to check on a patient to verify their status and help them if needed (e.g., in the event of a fall).

[0132] Examples

[0133] Example 1

[0134] Example 1 provides a non-limiting example implementation of the aggregation of point cloud data into a custom JSON format. Complex point cloud information is condensed into a compact structure that prioritizes efficiency and privacy preservation, while reducing data volume, which allows for computationally and cost efficient microprocessing.

[0135] This implementation involves a novel post-processing procedure where the raw 3D point cloud data include individual coordinates (x, y, z), velocities, and signal strengths derived from FMCW radar reflections. These point cloud data are analyzed on-device or in the edge computing layer to extract and summarize key height metrics (e.g., minimum and maximum z-values per detected track or cluster, associated with a track identifier), timestamps in Unix epoch and human-readable formats, and the total count of -40- QB\920171.00672\100158611.4Client Ref. UMN 2025-119detected points, thereby achieving an approximate 80-90% reduction in data volume compared to transmitting the full point cloud (e.g., from thousands of points / frame to <100 bytes of essentials).

[0136] For example, in a typical frame of l / 20thof a second, a standard raw TLV-parsed point cloud may contain 100-500 points with attributes (e.g., x, y, z, Doppler velocity, SNR, track details, gesture classifications, raw ADC samples, compressed points, configuration references, side information, processing statistics, spherical coordinates, presence indicators, classifiers, and so forth), equating to several KB per frame, which adds to the computational load (e.g., storage, transmission, and analysis). Using the described example pipeline, post-aggregation, the custom JSON retains only per-track height extrema (e.g., maximum of 2-5 tracks), a single point count integer, and frame / timestamp metadata, which typically equates to <200 bytes / frame. Empirical testing shows 85% average reduction across varied activity levels, as non-essential dimensions and granular points are permanently discarded, supporting low-power loT transmission in bandwidth-constrained elderly care deployments. This enables efficient longitudinal tracking (e.g., correlating height trends with clinical metrics) while precluding reverse-engineering of full body kinematics.

[0137] Unlike systems relying on full / sparse point clouds for server-side deep learning (e.g., PointNet / CNN classification or variational autoencoders for anomaly spikes), this method performs irreversible edge-side minimization, aligning with data protection principles (e.g., minimization under GDPR-like frameworks). It complements on-sensor tracking (e.g., height estimation in standard configs) by adding custom clustering / filtering for multi-person robustness and explicit privacy safeguards, without requiring high-compute ML inference locally.

[0138] The data summarization that achieves these features is performed through -41- QB\920171.00672\100158611.4Client Ref. UMN 2025-119algorithmic steps such as clustering points via density-based methods (e.g., identifying body-related clusters from human movements), computing statistical aggregates on z-coordinates for height-focused insights, and serializing only these essentials into a lightweight JSON structure, which prioritizes transmission efficiency and privacy by omitting granular spatial details that could enable pose reconstruction. This procedure focuses on height-centric aggregation for health monitoring applications, enabling rapid, low-bandwidth analysis of time-series changes (e.g., head height drops for fall detection) without the computational overhead of full datasets.

[0139] The example implementation uses the software code files described below.

[0140] 1. Type Length Value

[0141] This file defines constants for TLV (Type Length Value) types used in radar data parsing. The custom configuration influences it indirectly by specifying which TLVs (e.g., detected points, tracks, side info) are enabled in the sensor output; processing here determines JSON by providing the mapping for downstream parsers to identify and extract relevant data fields like point clouds, which are later aggregated into height metrics and point counts in the custom format.

[0142] 2. Graphical User Interface Processing

[0143] This file contains utility functions like sphericalToCartesianPointCloud for coordinate conversions and constants for classifiers. The custom configuration affects it through antenna geometry and phase rotation settings, which optimize conversions for accurate z-height extraction; processing contributes to JSON output by enabling novel behavior classification, ensuring summarized metrics (e.g., number of detected points) reflect room-dependent human activity for the final aggregated format.

[0144] While the example implementation does not require the use of a graphical user interface, this file supports the pipeline by providing utility functions and constants -42- QB\920171.00672\100158611.4Client Ref. UMN 2025-119that are used in data processing and analysis. Specifically, it includes procedures like sphericalToCartesianPointCloud for converting radar data coordinates, which help provide for accurate point cloud manipulation in tracking algorithms, ensuring the program's core monitoring functions like height summarization for fall detection operate correctly without relying on visual rendering. This allows the process to function in non-GUI modes such as cloud-based aggregation or embedded edge processing, where efficiency and privacy are prioritized over user-facing displays.

[0145] 3. Parse Type Length Value

[0146] This file implements parsing functions for specific TLV types. The custom configuration determines which TLVs are present (e.g., via profileCfg and trackingCfg enabling height / track data). Processing here extracts raw points, tracks, and heights, directly feeding into aggregation by computing summaries like min / max z-values, which are important for the custom JSON's height metrics and point counts, reducing volume through selective feature isolation.

[0147] 4. Parse Frame

[0148] This file decodes frame headers and calls TLV parsers to assemble output dictionaries (e.g., 'pointCloud', 'numDetectedPoints'J. The custom configuration sets frame structure (e.g., frameCfg for number of chirps / loops) and platform, influencing data integrity checks. Processing determines JSON by compiling the full parsed frame, including frame number and detected points, which are aggregated into the custom format for timestamped summaries, ensuring data reduction by filtering invalid TLVs early.

[0149] 5. Fall detection

[0150] This file defines the FallDetection class for height buffer analysis and fall alerts. The custom configuration optimizes tracker parameters (e.g., stateParam,-43- QB\920171.00672\100158611.4Client Ref. UMN 2025-119allocationParam) for accurate height tracking. Processing analyzes time-series heights [e.g., via deque buffers for min / max over 1.5 s thresholds), determining JSON output by generating 'HeightData' summaries [e.g., [track ID, current height, previous height]), a novel procedure for aggregating point-derived metrics into compact fall indicators.

[0151] 6. Datastream

[0152] This file handles UART parsing [UARTParser class) and sends configs to the sensor. The custom configuration is loaded here [sendCfg method), directly determining sensor output TLVs; processing reads and parses frames [readAndParseUartDoubleCOMPort calling parseFrame.py), outputting dictionaries like 'pointCloud' and 'numDetectedPoints', which are aggregated into JSON, ensuring the custom format's efficiency by minimizing raw binary handling.

[0153] 7. Main python application

[0154] This file orchestrates the core loop, initializing the parser and aggregating parsed data into JSON. The custom configuration is applied via the parser. Processing steps include calling fall_detection.py for height summaries, adding timestamps, and serializing frameJSON [with 'frameNumber', 'HeightData', 'PointsDetected'), determining the final custom JSON output through novel aggregation that reduces volume by summarizing instead of including full points.

[0155] 8. Human Activity Recognition

[0156] This file manages tracking and visualization. The custom configuration parseTrackingCfg] sets maxTracks and boundaries, influencing trackData. Processing computes heights and falls from points, feeding into JSON aggregates like 'HeightData', determining output by enabling room-dependent classification that refines point counts for the custom format.

[0157] 9. Visualize.44.QB\920171.00672\100158611.4Client Ref. UMN 2025-119

[0158] This file handles live visualization (LiveSensorVisualization class). The custom configuration indirectly affects data via the parser. Processing updates plots from trial_output (e.g., pointCloud to 3D scatter, heightData to bars) but does not directly output JSON. Aggregates used in the custom format are validated, ensuring the summarized metrics align with visual insights for health monitoring.

[0159] Table 1 provides descriptions of the computational functions and software library referenced above.

[0160] Table 1-45- QB\920171.00672\100158611.4Client Ref. UMN 2025-119

[0161] Example 2

[0162] The following provides a non-limiting example of a configuration file that can be used to set the sensor parameters that control the radio wave parameters (e.g., frequency modulation) and preprocessing layer (e.g., detection layer and tracking layer) parameters. Table 2 shows the custom binary configuration, which includes customized chirp profiles, CFAR layers, tracker params like 0° elevation, human-scale boundaries, and lowered thresholds for small movements, primes the raw output for height-focused aggregation. This creates a tailored pipeline where upstream sensor tweaks (distinct from general-purpose configurations) directly optimize downstream JSON summaries for fall-risk biomechanics, rather than broad surveillance. This configuration differs from standard setups, which use elevated sensor positions, broader state transitions, higher allocation thresholds, minimal acceleration limits, and basic tracking modes suited for general people counting rather than health-specific applications, resulting in less sensitivity to ground-level events and higher computational demands for clutter rejection.-46- QB\920171.00672\100158611.4Client Ref. UMN 2025-119

[0163] Table 2 provides a non-limiting example of configuration parameters. The right hand column describes each parameter.

[0164] Table 2-47- QB\920171.00672\100158611.4Client Ref. UMN 2025-119

[0165] Example 3

[0166] FIG. 3 provides a block diagram that demonstrates an implementation of an example process for monitoring the health status of patients within a care facility.

[0167] Example 4

[0168] The following example illustrates how the radar-derived aggregate activity data correlate with cognitive decline as measured by the MoCA. The aggregate activity data, which may be referred to as "activity points” or "total activity points”, representing aggregated human movement detections from point cloud data, as previously described.

[0169] Based on established research linking reduced physical activity to cognitive impairment (e.g., studies showing that lower activity levels are associated with declining MoCA scores in aging populations, with high activity improving scores by up to 15% over 12 months and reducing dementia risk by 28%), a scenario was simulated for -48- QB\920171.00672\100158611.4Client Ref. UMN 2025-119an elderly individual with emerging mild cognitive impairment (MCI). The radar system monitors daily activity in a memory care setting, where "Activity Points" quantifies movement intensity (higher points indicate more dynamic activity like walking; lower points suggest sedentary behavior or reduced mobility). Over 12 months, a projected gradual decline in average daily points from ~2000 (active baseline) to ~500 (increasingly sedentary), correlating with MoCA scores dropping from 28 (normal) to ~22 (MCI threshold). This correlation could enable predictive alerts, such as notifying caregivers when sustained low points precede MoCA drops, facilitating early interventions like physical therapy to mitigate decline.

[0170] Table 3 shows simulated longitudinal data

[0171] Table 3

[0172] The described system can analyze longitudinal changes in activity levels,-49- QB\920171.00672\100158611.4Client Ref. UMN 2025-119such as a progressive reduction in the normalized rate of detected points over time, rather than relying on absolute activity points, as the latter may vary substantially depending on the configuration of the multi-sensor array, including factors like the number of sensors, their spatial placement, room geometry, or environmental obstructions that influence overall detection coverage and signal aggregation. For instance, in a densely instrumented facility with multiple overlapping sensors, absolute daily point counts might exceed those from a sparse single-sensor setup for equivalent physical activity, potentially by 50-200% due to enhanced resolution and reduced blind spots. By focusing on relative changes (e.g., a 25-40% decline in activity points over several months, normalized to baseline levels), the method ensures robustness across diverse deployments, mitigating variability without requiring site-specific recalibration and enabling predictive modeling that forecasts MoCA score deterioration (e.g., from 28 to 22) based on sustained trends indicative of increasing sedentary behavior or mobility impairment. This change-oriented approach, integrated with machine learning algorithms, facilitates early detection of cognitive decline in vulnerable populations, supporting timely interventions like physical therapy programs to potentially arrest progression, while aligning with the system's scalable design for applications in memory care or rural settings.

[0173] Example 5

[0174] The following example provides various example applications of the systems and methods described herein.

[0175] In a 3-12 month study of 20 AD / ADRD patients in a memory care facility equipped with the multisensor dynamic array, aggregated activity points (e.g., 10-30 million points / day declining 5-20% over the period) correlate to MoCA score drops from 22 to 18, enabling predictive alerts for interventions such as medication adjustments or -50- QB\920171.00672\100158611.4Client Ref. UMN 2025-119increased supervision. Real-time fall alerts reduce response times by 50%, preventing secondary injuries, while longitudinal analysis using cyclomatic complexity (e.g., increasing from 5 to 15 due to fragmented paths) flags sundowning onset for early behavioral therapies.

[0176] For pediatric applications, in a simulated NICU bridge care setting with 10-50 infants, the system detects respiratory pauses greater than 15 seconds, triggering alerts and reducing SIDS risks.

[0177] Example 6

[0178] The following provides an example of aggregate motion data measured over 2 frames with a frame rate of l / 20thsecond. The TrameNumber’ keeps track of the chronological order of data to allow tracking and characterization of patterns through time. The ‘HeightData’ includes a tracking identification number and upper and lower statistical bounds of a patient’s head height, respectively. The ‘timestamp’ is given as a universal Unix timestamp and converted into human-readable time in ‘CurrTime’. The ‘PointsDetected’ provides aggregate activity data, characterizing the amount of activity measured within the frame.

[0179] {'TrameNumber": 350,

[0180] "HeightData": [[2.0, 1.7724049091339111, 1.5744303464889526]],

[0181] "timestamp": 1738689419.815184,

[0182] "CurrTime": "Tue Feb 411:16:592025",

[0183] "PointsDetected": 20},

[0184] {" frameNumber": 351,

[0185] "HeightData": [[2.0, 1.7828713655471802, 1.5938029289245605]],

[0186] "timestamp": 1738689419.8776836,

[0187] "CurrTime": "Tue Feb 411:16:592025",-51- QB\920171.00672\100158611.4Client Ref. UMN 2025-119

[0188] "PointsDetected": 8}

[0189] Table 4 lists the computational requirements for the present example in which the data are aggregated, stored, and transmitted in the custom JSON format shown above.

[0190] Table 4

[0191] Without aggregating the data as previously described, the data for a single -52- QB\920171.00672\100158611.4Client Ref. UMN 2025-119frame, stored in a similar JSON format would typically include the following:

[0192] "frameNumber": 100,

[0193] "timestamp": 1627890123,

[0194] "CurrTime": "Tue Feb 411:16:592025",

[0195] numDetectedPoints": 5,

[0196] "pointCloud": [{"x": 1.2, "y": 0.5, "z": 0.8, "doppler": 0.3, "snr": 15},

[0197] {"x": 1.3, "y": 0.6, "z": 0.7, "doppler": 0.4, "snr": 14},

[0198] {"x": 1.4, "y": 0.7, "z": 0.6, "doppler": 0.2, "snr": 16},

[0199] {"x": 1.5, "y": 0.8, "z": 0.5, "doppler": 0.1, "snr": 12},

[0200] {"x": 1.6, "y": 0.9, "z": 0.4, "doppler": 0.5, "snr": 18}],

[0201] numTracks": 2,

[0202] "tracks": [{"tid": 1, "posX": 2.0, "posY": 1.5, "velX": 0.2, "velY": 0.1},

[0203] {"tid": 2, "posX": 3.0, "posY": 2.5, "velX": 0.3, "velY": -0.1}],

[0204] "vitalSigns": {"heartRate": 72, "breathRate": 15},

[0205] "gesture": "swipejeft",

[0206] "adcSamples": [1024, 1050, 1035],

[0207] "compressedPoints": [{"rangeldx": 10, "dopplerldx": 5, "peakVal": 2000}],

[0208] "configUsed": " 68xx.mmwave.json",

[0209] "HeightData": [[2.0, 1.72321355342865, 1.527090073]],

[0210] "targets": [{"tid": 3, "x": 4.0, "y": 3.0, "vx": 0.4, "vy": 0.2}],

[0211] "breathRate": 18,

[0212] "rangeBin": 10,

[0213] "sideinfo": [{"snr": 20, "noise": 5}],

[0214] "stats": {"interFrameProcTime": 30,

[0215] "transmitOutTime": 10},-53- QB\920171.00672\100158611.4Client Ref. UMN 2025-119

[0216] "sphericalPoints": [{"range": 2.5, "azimuth": 45, "elevation": 10, "doppler": 0.6}],

[0217] presence": true,

[0218] classifier": "human"

[0219] In the present example, the computational requirements for processing this full JSON structure would include the estimates shown in Table 5.

[0220] Table 5-54- QB\920171.00672\100158611.4Client Ref. UMN 2025-119-55- QB\920171.00672\100158611.4Client Ref. UMN 2025-119

[0221] Example 7

[0222] FIGS. 4A and 4B provide an example of a visualization of data that may be provided for a patient. FIG. 4a shows activity levels quantified based on the aggregate activity data over the course of a week. FIG.4B shows activity levels quantified based on the aggregate activity data further aggregated for each month over the course of a year. These activity levels are plotted along with MoCA scores to show correlating trends.

[0223] Example 8

[0224] FIG. 5 shows a flow chart illustrating an example implementation of monitoring a health status for a patient or group of patients.

[0225] In some implementations, the system and methods described herein can-56- QB\920171.00672\100158611.4Client Ref. UMN 2025-119operate through a series of interconnected processing stages, as illustrated in FIG. 5, to enable noninvasive and contactless monitoring of human subjects. These stages collectively facilitate the acquisition, analysis, and interpretation of radar-derived data to detect falls, monitor activity, and assess health-related parameters. The following description elucidates the functionality at each stage, with reference to exemplary implementations embodied in the previously provided source code files, which serve as non-limiting examples of how the invention may be practiced.

[0226] Beginning with the configuration file stage, the system receives parameters that define operational settings, such as sensor calibration, boundary definitions, and detection thresholds. This initial input establishes the framework for subsequent processing, ensuring that the monitoring device is tailored to specific environments, such as indoor spaces or health facilities. This stage configures the radar sensor to optimize signal transmission and reception, thereby preparing the device for data capture. Source code files that handle configuration loading and application facilitate seamless integration of user-defined parameters into the overall monitoring process.

[0227] Following configuration, the system proceeds to initialization and control, wherein hardware components are activated, and communication protocols are established. This stage ensures stable connectivity between the monitoring device and associated processing units, enabling reliable data flow. The system adjusts sensor placement and operational modes based on architectural layouts or environmental factors. Code for system setup and control initializes routines and error handling to maintain operational integrity.

[0228] The next stage involves UART and raw data acquisition, where the system captures unprocessed signals from the radar sensor via a UART interface. This acquisition captures reflection data indicative of object positions and movements within the -57- QB\920171.00672\100158611.4Client Ref. UMN 2025-119monitored space. This stage gathers raw inputs without physical interaction, preserving user privacy. Implementations in the source code files for data streaming and serial communication achieve this by efficiently reading and buffering incoming signals for further processing.

[0229] Subsequently, the system engages in time, length, and value parsing, coupled with point cloud extraction. Here, the acquired data is dissected into discrete elements, including temporal stamps, signal magnitudes, and spatial coordinates, to form a preliminary representation of detected points. This parsing refines the raw inputs into a structured format suitable for analysis, providing accurate point cloud generation for fall detection and activity monitoring. Source code files handling type-length-value structures decode and organize the data into usable arrays.

[0230] Frame assembly and validation follow, wherein individual data packets are compiled into coherent frames and verified for completeness and accuracy. This stage mitigates potential errors from transmission artifacts, ensuring that only valid frames advance. The system discards anomalous frames to maintain reliability. Exemplary code in files for frame parsing and validation embodies this by employing checks and assembly logic to produce robust datasets.

[0231] Pre-processing and motion analysis ensue, where the assembled frames undergo preliminary refinement to identify motion states. This involves filtering noise and analyzing signal reflections to discern dynamic elements from static backgrounds. This stage computes basic kinematic properties, setting the foundation for higher-level interpretations. Computer code provides graphical user interface commons and preprocessing routines that applying transformations to enhance data quality.

[0232] The processing of reflection data, such as through two-dimensional fast Fourier transforms, determines detailed motion states. This stage extracts parameters -58- QB\920171.00672\100158611.4Client Ref. UMN 2025-119like azimuth, elevation, range, velocity, and signal-to-noise ratios, providing a comprehensive view of subject movements. This step enables precise localization and velocity assessment. Although certain computational aspects occur on the device, source code files for type-length-value definitions and parsing support this by facilitating the interpretation of processed outputs.

[0233] Human activity recognition and identification occur next, wherein patterns in the motion data are evaluated to classify behaviors, such as walking or resting. This stage employs heuristics to distinguish human subjects from environmental objects, providing multi-person tracking. Source code files for people tracking and graphical utilities demonstrate this by correlating data points with behavioral models.

[0234] Multi-target tracking integrates the recognized activities across multiple subjects, maintaining continuity of monitoring in shared spaces. This stage applies tracking algorithms to associate data points over time, supporting dynamic array configurations and real-time alerts. Implementations in tracking-specific source code files embody this by managing target indices and trajectories.

[0235] Outputs from this tracking, including azimuth, elevation, range, velocity, and signal-to-noise ratios, are generated for further use. These parameters inform subsequent analyses, such as data extraction for health monitoring.

[0236] Micro-Doppler filtering refines velocity signatures to isolate subtle movements, enhancing detection accuracy. This stage filters micro-motions to focus on human-specific patterns. Source code for parsing type-length-values aids in handling these refined signals.

[0237] Velocity data extraction and acceleration computation derive metrics like speed changes and height extrema, important for fall prediction.

[0238] Human isolation applies filtering to segregate human signals from -59- QB\920171.00672\100158611.4Client Ref. UMN 2025-119background interference. Source code for fall detection and new fall detection variants supports this by focusing on relevant data streams. Acceleration and height extreme calculations determine minimum and maximum values, enabling threshold-based alerts. These data can be used for fall detection via head height monitoring.

[0239] Body-region segmentation divides detected points into anatomical regions, such as head, torso, and limbs, facilitating targeted analysis. Machine-learning can be used for classification.

[0240] Machine learning applied to head height changes and velocity infers human activity and health states. This culminates in outputs like fall alerts or activity trends, allowing predictive modeling and chronic disease correlation. Throughout these stages, the system ensures privacy-preserving operation, with source code files collectively providing embodiments for scalable, contactless monitoring in diverse applications.

[0241] Example 9

[0242] FIG. 6 shows a flow chart illustrating an example implementation of a computer architecture that can be used to perform the methods described herein.

[0243] The system and methods described herein extend beyond edge-device processing to encompass a cloud-based processing pipeline, as illustrated in the FIG.6, to enable scalable, secure, and longitudinal analysis of noninvasive monitoring data. This pipeline integrates data from one or more edge sensors, applies validation and fusion techniques, and generates actionable health metrics, thereby supporting real-time notifications, predictive modeling, and chronic disease progression monitoring. The following description elucidates the functionality at each stage of the cloud processing pipeline, with reference to exemplary implementations.

[0244] Commencing with the input from single or multiple edge sensors, the system acquires raw reflection signals generated by contactless radar devices monitoring -60- QB\920171.00672\100158611.4Client Ref. UMN 2025-119human subjects. This stage captures spatial and temporal data points indicative of positions, velocities, and activities. The sensors transmit this data securely, ensuring privacy preservation via anonymized data handling.

[0245] The secure message bus then facilitates the transmission of these signals to a centralized broker, employing encrypted protocols to maintain data integrity during transit. This intermediary stage segregates alert-oriented and data-storage streams, enabling efficient routing without compromising security.

[0246] Upon receipt by the MQTT message broker, the data are distributed along parallel paths: a real-time path for immediate processing and a longitudinal path for aggregated analysis. This bifurcation allows scalable monitoring, allowing simultaneous handling of urgent events and historical trends.

[0247] In the real-time path, routing and validation rules are applied to assess the incoming data for completeness, accuracy, and relevance. Valid data proceeds to further stages, while invalid data is segregated to prevent propagation of errors. This ensures data integrity, ensuring only reliable inputs inform subsequent decisions.

[0248] Valid data enters stream processing, where continuous small-batch operations refine the inputs into structured formats suitable for immediate analysis. This stage computes parameters like head height changes and velocity thresholds, generating preliminary alerts for conditions such as falls in vulnerable populations.

[0249] Processed streams are then stored in a time-series database, which organizes the data chronologically for efficient retrieval. This facilitates tracking of timeseries trends, enabling correlations between activity levels and health indicators over short intervals.

[0250] Concurrently or sequentially, raw data archives receive scheduled batch inputs from both paths, providing a persistent storage mechanism for unprocessed or -61- QB\920171.00672\100158611.4Client Ref. UMN 2025-119partially processed signals. This archival stage allows for longitudinal analysis, including retrospective review and model training without real-time constraints.

[0251] Multi-sensor fusion processing integrates data from disparate sources, applying time alignment to synchronize inputs, algorithmic processing to derive composite metrics, and patient decision logic to interpret results in a clinical context. This enables predictive modeling, such as fall risk assessment using multivariate heuristics or correlations with assessments like the Montreal Cognitive Assessment for Alzheimer's progression. It also supports pediatric applications by merging vital signs data to mitigate risks like sudden infant death syndrome.

[0252] The fused outputs feed into a clinical data dashboard, which visualizes health metrics for authorized users. This interface provides room-dependent behavior recognition, displaying patterns like bathroom entries for urinary tract infection detection or sedentary behavior monitoring.

[0253] Analytics and reporting engines then process the dashboard data to generate insights, such as disease stage transitions in Parkinson's or cognitive status changes. This stage can implement machine learning-based visualizations, producing reports that correlate radar-derived trends with clinical benchmarks.

[0254] For advanced analysis, a large language model tool interfaces with the analytics outputs, enabling natural language queries and hypothesis generation.

[0255] In parallel, real-time alert notification publishers disseminate urgent findings, such as detected falls or vital sign anomalies, via mobile or cloud-connected systems. This notification mechanism supports dual-channel architecture, delivering immediate alerts while routing detailed data for storage.

[0256] Long-term object storage archives these notifications and associated data, ensuring compliance with retention requirements and enabling historical queries. This -62- QB\920171.00672\100158611.4Client Ref. UMN 2025-119storage facilitates organization-wide configurations, supporting scalable deployments across health facilities.

[0257] Finally, user dashboards consolidate outputs from notifications and storage, providing intuitive interfaces for caregivers or clinicians. These dashboards provides comprehensive monitoring, displaying real-time and longitudinal views to inform interventions and reduce injury risks.

[0258] Throughout the cloud pipeline, the system maintains ethical considerations, such as consent via authorized representatives, and achieves performance metrics like high sensitivity and specificity. This integrated approach extends the edge-device capabilities, enabling robust, privacy-preserving health monitoring across diverse applications.

[0259] Example 10

[0260] The following example illustrates a representative configuration of the noninvasive health monitoring system deployed in a memory care facility environment.

[0261] A noninvasive health monitoring system is deployed at Mount Olivet Home, a memory care facility in Minneapolis, Minnesota. The deployment targets the 3rd floor memory care unit comprising 10 patient rooms for individuals with Alzheimer's Disease and Alzheimer's Disease Related Dementias (AD / ADRD).

[0262] System Configuration

[0263] The system comprises 30-40 ambient sensing devices deployed across the 10 patient rooms. Each patient room measures approximately 25 feet by 14 feet and includes a bedroom area, bathroom, and living space. Three to four sensors are positioned in each room to provide complete spatial coverage, as illustrated in FIGS. 7A and 7B, which depicts a dynamic multisensor array configuration showcasing the customizable ability to provide full coverage in the living room, bathroom, and hallway -63- QB\920171.00672\100158611.4Client Ref. UMN 2025-119of a typical 25 ft by 14 ft memory care living space. As another non-limiting example, even more sensors (e.g., 5+) can be placed within each space, such that the sensors have overlapping fields of view to provide spatial coverage from varying perspectives.

[0264] Each sensor device measures approximately 2 inches by 2 inches by 1 inch, as shown in FIG. 1A, and is housed in a compact white enclosure for unobtrusive wall mounting. The compact form factor integrates both sensing and computational capabilities into a standalone device without requiring an external computer for operation. Each sensor unit comprises an IWR6843 Texas Instruments FMCW radar module operating at 77 GHz, a Sona wireless communication module, an STM microcontroller, and a custom printed circuit board integrating all components. The bill of materials cost is approximately $250 per device.

[0265] FIG.8 depicts the floor plan layout of the memory care facility showing the arrangement of ten patient rooms where the multisensor dynamic array is deployed. Each patient room includes distinct functional areas including bedrooms, bathrooms, and living spaces, with sensors positioned in each functional zone to provide comprehensive coverage for fall detection and activity monitoring.

[0266] FIG.9 depicts an alpha prototype of the ambient device engineered during the discovery and ideation phase. The prototype comprises a Raspberry Pi 5 computing platform connected to a radar sensor module, representing the initial hardware architecture before miniaturization into the compact 2 inch by 2 inch by 1 inch enclosure shown in FIG. 1A. The alpha prototype configuration relies on the Raspberry Pi for data processing, which the production device replaces with a custom printed circuit board integrating all sensing and computational capabilities into a standalone unit.

[0267] Data Collection

[0268] Each sensor produces 20 frames per second of point cloud data. The data -64- QB\920171.00672\100158611.4Client Ref. UMN 2025-119collected in each frame includes frame number, height data, time stamp, current time, point count, and fall detection status. The system collects continuous data 24 / 7, generating approximately 1 billion data points per year for each monitored individual.

[0269] Machine Learning Algorithm Library

[0270] The processing unit executes a machine learning algorithm library that includes the following. The Fall Detection Algorithm identifies fall events based on changes in head height over a threshold of 10 frames (0.5 seconds). The algorithm detects three biomechanical fall types, including anterior-posterior falls (91% sensitivity), medial-lateral falls (92% sensitivity), and collapse falls (75% sensitivity). The Patient-on-Floor Detection Algorithm activates when the sensor detects an individual's head below 36 inches for more than 15 seconds, addressing slow falls where velocity thresholds are not exceeded. The Human Activity Recognition Algorithm classifies activities using a k-nearest neighbors classifier with k = 12, recognizing states including standing, sitting, sleeping, walking, and on-the-floor. The Room-Dependent Behavior Recognition Algorithm tags detected activities with room labels (bedroom, bathroom, living room, hallway) based on the sensor placement configuration shown in FIGS. 7A, 7B, and 8, enabling tracking of bathroom visits, sleep patterns, and room transitions. The Metabolic Expenditure Estimation Algorithm converts movement velocities into MET values: sedentary (1.0-1.5 METs) for velocity < 0.1 m / s; light activity (1.6-2.9 METs) for velocity 0.1-0.5 m / s; moderate activity (3.0-5.9 METs) for velocity 0.5-1.5 m / s; and vigorous activity (>6.0 METs) for velocity > 1.5 m / s. The Cyclomatic Complexity Analysis Algorithm calculates movement complexity according to M = E - N + 2P, where E represents walking paths, N represents number of rooms, and P represents total number of connected rooms. Changes in movement complexity patterns are correlated with progression of cognitive impairment. The Sundowning Detection Algorithm identifies -65- QB\920171.00672\100158611.4Client Ref. UMN 2025-119increased movement complexity, repetitive trajectory loops, and agitation patterns during evening hours (4 PM - 8 PM).

[0271] Alert System

[0272] The alert system transmits notifications to nursing staff including critical alerts for detected falls and individuals on floor exceeding 15 seconds, warning alerts for unusual bathroom patterns and sundowning behavior, and informational alerts for daily activity summaries and weekly trend reports.

[0273] Performance Metrics

[0274] Target performance metrics include 98% fall detection sensitivity, 98% specificity, and response time under 1 second from fall event to caregiver notification. Preliminary laboratory studies using the alpha prototype shown in FIG. 9 demonstrate overall fall detection sensitivity of 89% across 748 test scenarios.

[0275] Clinical lntegration

[0276] Movement data is mapped to Minimum Data Set (MDS) 3.0 Section G (Functional Status) items, supplementing periodic 90-day assessments with continuous real-time monitoring of functional status changes.

[0277] Privacy Considerations

[0278] The FMCW radar sensors do not capture identifiable images, addressing privacy concerns that limit adoption of camera-based systems. Data is represented as abstract point clouds rather than recognizable human forms. The compact device design shown in FIG. 1A enables unobtrusive installation that blends into typical residential or healthcare facility environments.

[0279] Results

[0280] The deployment demonstrates feasibility of a multisensor FMCW radar system in a real-world memory care environment configured as shown in FIGS. 7A, 7B,-66- QB\920171.00672\100158611.4Client Ref. UMN 2025-119and 8, providing continuous 24 / 7 monitoring without requiring resident compliance, privacy-preserving monitoring in bedrooms and bathrooms, real-time fall detection with immediate caregiver notification, and longitudinal activity data enabling detection of functional status changes and cognitive decline indicators.

[0281] Example 11

[0282] The following example illustrates a representative configuration of the noninvasive health monitoring system for activity trend analysis and fall detection in a memory care facility environment.

[0283] A noninvasive health monitoring system is deployed at Mount Olivet Memory Care facility for monitoring individuals with Alzheimer's Disease and Alzheimer's Disease Related Dementias (AD / ADRD). The system utilizes a dual-channel data architecture for real-time fall alerts and longitudinal activity trend analysis.

[0284] System Configuration

[0285] The system comprises a compact 3 inch by 2 inch ambient device utilizing Frequency Modulated Continuous Wave (FMCW) radar and machine learning for noninvasive, contactless fall detection. The device is installed in resident rooms with a multisensor layout ensuring comprehensive coverage of living areas, bathrooms (containing toilet and sink), and hallways while sensing around obstacles such as furniture.

[0286] Dual-Channel Data Architecture

[0287] The system processes data through two channels via Message Queuing Telemetry Transport (MQTT) and a lightweight publish-subscribe protocol for loT devices. The alert channel provides immediate fall notifications to nurses' smartphones with real-time alerts (e.g., "Fall Detection Alert" with timestamp). Fall events detected on the device trigger mobile alerts to caregivers with response time under 10 seconds from -67- QB\920171.00672\100158611.4Client Ref. UMN 2025-119sensor detection to notification delivery. The data channel transmits time-series data to Amazon Web Services ( WS) cloud for storage and longitudinal analysis. The time-series head height data of the resident, as shown in FIG. 10, is stored and analyzed to confirm device alerts, reducing false positives and negatives through human-in-the-loop (HITL) confirmation.

[0288] Time-Series Activity Classification

[0289] FIG. 10 illustrates a 24-hour activity trend visualization plotting average head height (y-axis, meters) against time (x-axis, midnight to 11:00 PM). The system classifies activity states based on head height thresholds, where < 0.5 m indicates a fall is detected, 0.5- 1.0 m indicates sleeping, 0.5- 1.3 m indicates sitting, and > 1.3 m indicates active.

[0290] The graph in FIG. 10 demonstrates how the system captures longitudinal movement data throughout a 24-hour period, with a confirmed fall event highlighted in. HITL review of time-series data enhances fall confirmation by cross-referencing instantaneous events such as rapid height drops from 1.5 m to less than 0.6 m in under 1.5 seconds, distinguishing true falls from false positives (e.g., bending) and false negatives (e.g., slow collapses).

[0291] Activity Points Feature

[0292] The system includes Activity Points, a novel feature that measures velocity of movement similar to inertial measurement units (IMUs) in wearable devices. Activity Points enable measurement of activity mobility with a contactless device, quantifying activity intensity, duration, and frequency to assess daily activity levels and sedentary behavior patterns.

[0293] Spatial-Temporal Activity Distribution

[0294] FIG. 11 depicts a multisensor activity distribution visualization trained on -68- QB\920171.00672\100158611.4Client Ref. UMN 2025-1193 gigabytes of simulated data. The figure plots sensor placement on the x-axis against estimated time spent in specific areas of a resident's living space on the y-axis, highlighting spatial-temporal activity patterns across different room locations including hallway, bathroom, and living room. The spatial-temporal heatmap visualization enables analysis of occupancy patterns across room layouts, time distribution in different functional areas, movement pattern changes over time, and behavioral shifts such as increased sedentary periods.

[0295] In this example, scaling multiple sensors (e.g., 3-5+) across multiple rooms generates a high-dimensional, temporally rich dataset from natural daily activities. This 'big data' approach, which leverages inexpensive, passively deployed devices, enables machine learning models to detect subtle changes in movement patterns that singlesensor or non-overlapping systems cannot reliably characterize.

[0296] Fall Detection Performance

[0297] Preliminary studies achieve 89% sensitivity across 1000 counts of simulated falls and nonfalls, validated with video and eyewitness ground truth. The system targets 98% sensitivity and specificity through continuous improvement and HITL optimization, matching the benchmark established by Al-video predicate devices.

[0298] The fall detection algorithm identifies three biomechanical fall types, including anterior-posterior falls with 91% sensitivity, medial-lateral falls with 92% sensitivity, and collapse falls with 75% sensitivity.

[0299] A patient-on-floor algorithm activates when the sensor detects an individual's head below 36 inches for more than 15 seconds, addressing collapse falls that occur without sufficient velocity to trigger standard fall detection thresholds.

[0300] Cognitive Health Monitoring

[0301] The system supports applications similar to accelerometer-based -69- QB\920171.00672\100158611.4Client Ref. UMN 2025-119actigraphy, quantifying activity patterns to assess sleep-wake cycles, daily activity levels, sedentary behavior, and mild cognitive impairment (MCI) through evolving movement patterns. The longitudinal dataset enables future research on activity trends and predictive modeling of movement patterns across time and position information to understand behavior patterns that may correlate with cognitive decline progression.

[0302] Clinical lntegration

[0303] Real-world fall accuracy is assessed using device logs cross-validated with facility incident reports and time-series data. For multi-person scenarios, classification ensures notifications for the monitored individual only, aligning with FDA single-resident indication. The system integrates with clinical workflows, with data supporting the Minimum Data Set (MDS) 3.0 assessment tool used in nursing homes.

[0304] Privacy Considerations

[0305] The FMCW radar sensors do not capture identifiable images, addressing privacy concerns that limit adoption of camera-based surveillance systems. The system provides monitoring in sensitive areas including bedrooms and bathrooms where 39% and 26% of falls occur respectively, areas where camera surveillance raises significant privacy concerns.

[0306] Results

[0307] The deployment demonstrates feasibility of a dual-channel FMCW radar system providing both real-time fall alerts and longitudinal activity trend analysis. The time-series visualization shown in FIG. 10 enables HITL confirmation of fall events, while the spatial-temporal activity distribution shown in FIG. 11 supports analysis of behavioral patterns and detection of changes that may indicate cognitive or physical health decline. The system provides continuous 24 / 7 monitoring without requiring resident compliance, enabling real-time alerts to caregivers and longitudinal data -70- QB\920171.00672\100158611.4Client Ref. UMN 2025-119analysis for clinical decision support.

[0308] Example 12

[0309] The following example illustrates a representative configuration of the noninvasive health monitoring system for fall detection and activity monitoring in an independent living facility environment.

[0310] A noninvasive health monitoring system is deployed in an independent living facility for monitoring individuals with Alzheimer's Disease and Alzheimer's Disease Related Dementias (AD / ADRD). The system utilizes ambient sensors and machine learning algorithms for fall detection, activity recognition, and cognitive health assessment.

[0311] System Architecture

[0312] FIG. 12 depicts the system architecture comprising an ambient sensor positioned in a resident room, cloud computing infrastructure containing an algorithm library, and mobile notification delivery to nursing staff. The ambient sensor detects patient movement and transmits data to cloud computing systems where the algorithm library processes the information for fall detection, movement trends, and sleep health analysis. Alerts and movement trend reports are delivered to nurses via mobile devices.

[0313] The system is designed for use across the continuum of care, from independent living to skilled nursing and hospice environments. The technology addresses the challenging combination of physically active individuals with AD / ADRD who require continuous monitoring without the compliance burden of wearable devices.

[0314] System Configuration

[0315] An ambient sensor and algorithms are developed in a resident room in an independent living facility. The dimensions of the room are used to create a virtual boundary that stops movement detection beyond the defined parameters, with the -71- QB\920171.00672\100158611.4Client Ref. UMN 2025-119information stored in a configuration file. The sensor is mounted on the wall and connected to a processing unit for real-time data processing.

[0316] The system sends, receives, and processes packets of data containing the coordinates of the individual represented by point cloud data and bounding box visualization on the user interface. The algorithm library interprets the body position of the individual and displays the current state.

[0317] Machine Learning Algorithm Library

[0318] The processing unit executes four primary algorithms determining the state of the individual. Standing State is characterized by head height near individual's standing height with low velocity magnitude. Resting State is characterized by head height at intermediate or bed level with very low velocity magnitude. On the Floor State is characterized by head height below sitting level with horizontal body orientation. Fall State is characterized by rapid downward velocity exceeding threshold with sudden transition to floor level.

[0319] Immediate notifications are sent to nursing staff if the individual is on the floor or falls. Standing and resting states are used for longitudinal data analysis to show trends over time with evidence-based interventions to prevent future adverse health events.

[0320] Fall Detection Algorithm

[0321] The fall detection algorithm is based on 3D position in the room, velocity, and acceleration of the individual. The measured height, average height, and short-term delta in height change are used to determine a fall event. A threshold of 10 frames or half a second is defined as the short-term delta.

[0322] Biomechanical Classification Performance

[0323] Table 6 depicts the biomechanical classification analysis results showing -72- QB\920171.00672\100158611.4Client Ref. UMN 2025-119true positive, false negative, and sensitivity metrics for different movement and fall types. The system achieves performance reported in Table 6.

[0324] Table 6

[0325] The sensor identifies collapse falls with approximately 15% less accuracy than other biomechanical fall types. An additional algorithm is developed to account for fall events that do not cross the velocity threshold.

[0326] Patient-on-Floor Algorithm

[0327] A patient-on-floor algorithm is developed for "soft" falls where an individual loses balance and leans against furniture and slowly lowers themselves onto the floor. When an individual falls without enough velocity to trigger the fall detection algorithm, the patient-on-floor algorithm activates anytime the sensor detects the head of the individual below 36 inches for more than 15 seconds.

[0328] This algorithm helps prevent "long-lie" events where an older individual is unable to get up after a fall. The effects of long-lie events include potential pressure injuries, loss of mobility, fear of future falls, and death if the individual is undiscovered for a prolonged period.

[0329] False Alarm Reduction

[0330] In scenarios where movement or other behaviors could be misinterpreted-73- QB\920171.00672\100158611.4Client Ref. UMN 2025-119by the sensor as a fall, such as tying a shoe or yoga on the floor, a false alarm could result if the change in head height rapidly moves toward the floor. The velocity algorithm is required to classify a patient fall and is measured by the change in head height over 10 frames.

[0331] Improvements to the system include human review of potential events to verify ground truth. A caregiver or family member receiving a fall notification asks the individual being monitored about the event. Qualitative feedback to confirm or deny the fall event is used to assess the accuracy of the system.

[0332] Cognitive Health Monitoring

[0333] Fragmented daily physical activity is associated with greater mortality risk. Such patterns manifest as active states with a duration of less than five minutes followed by a sedentary state and represent a potential sign of declining functional status. The ambient system determines fragmented activity patterns that correlate with cognitive health.

[0334] The system analyzes total daily activity, activity fragmentation, and periods of activity. This approach delivers results similar to wearable accelerometers without the need to manage battery charging, cleaning, and individual cooperation to wear a device.

[0335] Hierarchical Access Control

[0336] The hierarchy of the health organization is used as a framework for managing identity and access management. The Director of Nursing has access to all residents and patients, floor nurses have access only to their floor, and family members have access only to their loved one.

[0337] Privacy Considerations

[0338] The ambient sensor does not use cameras and requires no contact with the body. Research demonstrates that older adults are more likely to accept in-home sensing -74- QB\920171.00672\100158611.4Client Ref. UMN 2025-119technologies when they are unobtrusive, do not require wearing any device, do not interfere with daily life, do not require learning new technical skills, and do not capture video images. The system addresses privacy concerns that limit technology user acceptance of camera-based surveillance, particularly in bathrooms and bedrooms.

[0339] Advantages Over Existing Systems

[0340] Personal Emergency Response Systems (PERS) are unusable if the person is unconscious or unable to reach the button. Approximately 80% of older adults wearing a PERS do not use their alarm system to call for help after experiencing a fall. Wearable accelerometer sensitivity drops from 94% in simulated falls to 25% in real-world falls.

[0341] The ambient system achieves 89% sensitivity comparable to wearable accelerometry and camera-based surveillance systems while providing higher technology user acceptance due to the noninvasive, contactless approach.

[0342] Results

[0343] The ambient assisted living human activity recognition system correctly identifies falls with 89% sensitivity as shown in Table 4. The system provides noninvasive monitoring that improves confidence in older adults with the knowledge that a nurse is automatically notified if a fall event occurs. The system architecture shown in FIG. 12 enables scalable deployment across the continuum of care with real-time alerts and longitudinal movement trend analysis for clinical decision support.

[0344] Example systems

[0345] Referring now to FIG. 13, an example of a system 1300 is shown, which may be used in accordance with some aspects of the systems and methods described in the present disclosure. As shown in FIG. 13, a computing device 1350 can receive one or more types of data (e.g., radar data, processed radar data) from data source 1302. In some configurations, computing device 1350 can execute at least a portion of an health -75- QB\920171.00672\100158611.4Client Ref. UMN 2025-119monitoring system 1304 to process radar data or analyze aggregate motion data to determine a health status. In some configurations, the health monitoring system 1304 can implement an automated pipeline to provide health reports or alerts.

[0346] Additionally or alternatively, in some configurations, the computing device 1350 can communicate information about data received from the data source 1302 to a server 1352 over a communication network 1354, which can execute at least a portion of the health monitoring system 1304. In such configurations, the server 1352 can return information to the computing device 1350 (and / or any other suitable computing device) indicative of an output of the health monitoring system 1304.

[0347] In some configurations, computing device 1350 and / or server 1352 can be any suitable computing device or combination of devices, such as a desktop computer, a laptop computer, a smartphone, a tablet computer, a wearable computer, a server computer, a virtual machine being executed by a physical computing device, and so on. The computing device 1350 and / or server 1352 can also process radar data.

[0348] In some configurations, data source 1302 can be any suitable source of data (e.g., raw reflection data, processed radar data, aggregate motion data, historical health status data), such as an radar-based sensor system, another computing device (e.g., a server storing raw reflection data, processed radar data, aggregate motion data, historical health status data ), and so on. In some configurations, data source 1302 can be local to computing device 1350. For example, data source 1302 can be incorporated with computing device 1350 (e.g., computing device 1350 can be configured as part of a device for measuring, recording, estimating, acquiring, or otherwise collecting or storing data). As another example, data source 1302 can be connected to computing device 1350 by a cable, a direct wireless link, and so on. Additionally or alternatively, in some configurations, data source 1302 can be located locally and / or remotely from computing -76- QB\920171.00672\100158611.4Client Ref. UMN 2025-119device 1350, and can communicate data to computing device 1350 (and / or server 1352) via a communication network (e.g., communication network 1354).

[0349] In some configurations, communication network 1354 can be any suitable communication network or combination of communication networks. For example, communication network 1354 can include a Wi-Fi network (which can include one or more wireless routers, one or more switches, etc.), a peer-to-peer network (e.g., a Bluetooth network), a cellular network (e.g., a 3G network, a 4G network, etc., complying with any suitable standard, such as CDMA, GSM, LTE, LTE Advanced, WiMAX, etc.), other types of wireless network, a wired network, and so on. In some configurations, communication network 1354 can be a local area network, a wide area network, a public network (e.g., the Internet), a private or semi-private network (e.g., a corporate or university intranet), any other suitable type of network, or any suitable combination of networks. Communications links shown in FIG. 13 can each be any suitable communications link or combination of communications links, such as wired links, fiber optic links, Wi-Fi links, Bluetooth links, cellular links, and so on.

[0350] Referring now to FIG. 14, an example of hardware 1400 that can be used to implement data source 1302, computing device 1350, and server 1352 in accordance with some configurations of the systems and methods described in the present disclosure is shown.

[0351] As shown in FIG. 14, in some configurations, computing device 1350 can include a processor 1402, a display 1404, one or more inputs 1406, one or more communication systems 1408, and / or memory 1410. In some configurations, processor 1402 can be any suitable hardware processor or combination of processors, such as a central processing unit ("CPU”), a graphics processing unit ("GPU”), and so on. In some configurations, display 1404 can include any suitable display devices, such as a liquid -77- QB\920171.00672\100158611.4Client Ref. UMN 2025-119crystal display ("LCD”) screen, a light- emitting diode ("LED”) display, an organic LED ("OLED”) display, an electrophoretic display (e.g., an "e-ink” display), a computer monitor, a touchscreen, a television, and so on. In some configurations, inputs 1406 can include any suitable input devices and / or sensors that can be used to receive user input, such as a keyboard, a mouse, a touchscreen, a microphone, and so on.

[0352] In some configurations, communications systems 1408 can include any suitable hardware, firmware, and / or software for communicating information over communication network 1354 and / or any other suitable communication networks. For example, communications systems 1408 can include one or more transceivers, one or more communication chips and / or chip sets, and so on. In a more particular example, communications systems 1408 can include hardware, firmware, and / or software that can be used to establish a Wi-Fi connection, a Bluetooth connection, a cellular connection, an Ethernet connection, and so on.

[0353] In some configurations, memory 1410 can include any suitable storage device or devices that can be used to store instructions, values, data, or the like, that can be used, for example, by processor 1402 to present content using display 1404, to communicate with server 1352 via communications system(s) 1408, and so on. Memory 1410 can include any suitable volatile memory, non-volatile memory, storage, or any suitable combination thereof. For example, memory 1410 can include random-access memory ("RAM”), read-only memory ("ROM”), electrically programmable ROM ("EPROM”), electrically erasable ROM ("EEPROM”), other forms of volatile memory, other forms of non-volatile memory, one or more forms of semi-volatile memory, one or more flash drives, one or more hard disks, one or more solid state drives, one or more optical drives, and so on. In some configurations, memory 1410 can have encoded thereon, or otherwise stored therein, a computer program for controlling operation of computing -78- QB\920171.00672\100158611.4Client Ref. UMN 2025-119device 1350. In such configurations, processor 1402 can execute at least a portion of the computer program to present content (e.g., alerts, plots, images, user interfaces, graphics, tables), receive content from server 1352, transmit information to server 1352, and so on. For example, the processor 1402 and the memory 1410 can be configured to perform the methods described herein.

[0354] In some configurations, server 1352 can include a processor 1412, a display 1414, one or more inputs 1416, one or more communications systems 1418, and / or memory 1420. In some configurations, processor 1412 can be any suitable hardware processor or combination of processors, such as a CPU, a GPU, and so on. In some configurations, display 1414 can include any suitable display devices, such as an LCD screen, LED display, OLED display, electrophoretic display, a computer monitor, a touchscreen, a television, and so on. In some configurations, inputs 1416 can include any suitable input devices and / or sensors that can be used to receive user input, such as a keyboard, a mouse, a touchscreen, a microphone, and so on.

[0355] In some configurations, communications systems 1418 can include any suitable hardware, firmware, and / or software for communicating information over communication network 1354 and / or any other suitable communication networks. For example, communications systems 1418 can include one or more transceivers, one or more communication chips and / or chip sets, and so on. In a more particular example, communications systems 1418 can include hardware, firmware, and / or software that can be used to establish a Wi-Fi connection, a Bluetooth connection, a cellular connection, an Ethernet connection, and so on.

[0356] In some configurations, memory 1420 can include any suitable storage device or devices that can be used to store instructions, values, data, or the like, that can be used, for example, by processor 1412 to present content using display 1414, to -79- QB\920171.00672\100158611.4Client Ref. UMN 2025-119communicate with one or more computing devices 1350, and so on. Memory 1420 can include any suitable volatile memory, non-volatile memory, storage, or any suitable combination thereof. For example, memory 1420 can include RAM, ROM, EPROM, EEPROM, other types of volatile memory, other types of non-volatile memory, one or more types of semi-volatile memory, one or more flash drives, one or more hard disks, one or more solid state drives, one or more optical drives, and so on. In some configurations, memory 1420 can have encoded thereon a server program for controlling operation of server 1352. In such configurations, processor 1412 can execute at least a portion of the server program to transmit information and / or content (e.g., data, images, a user interface) to one or more computing devices 1350, receive information and / or content from one or more computing devices 1350, receive instructions from one or more devices (e.g., a personal computer, a laptop computer, a tablet computer, a smartphone), and so on.

[0357] In some configurations, the server 1352 is configured to perform the methods described in the present disclosure. For example, the processor 1412 and memory 1420 can be configured to perform the methods described herein.

[0358] In some configurations, data source 1302 can include a processor 1422, one or more data acquisition systems 1424, one or more communications systems 1426, and / or memory 1428. In some configurations, processor 1422 can be any suitable hardware processor or combination of processors, such as a CPU, a GPU, and so on. In some configurations, the one or more data acquisition systems 1424 are generally configured to acquire data, and can include a radar sensor system. Additionally or alternatively, in some configurations, the one or more data acquisition systems 1424 can include any suitable hardware, firmware, and / or software for coupling to and / or controlling operations of a radar sensor system. In some configurations, one or more -80- QB\920171.00672\100158611.4Client Ref. UMN 2025-119portions of the data acquisition system(s) 1424 can be removable and / or replaceable.

[0359] Note that, although not shown, data source 1302 can include any suitable inputs and / or outputs. For example, data source 1302 can include input devices and / or sensors that can be used to receive user input, such as a keyboard, a mouse, a touchscreen, a microphone, a trackpad, a trackball, and so on. As another example, data source 1302 can include any suitable display devices, such as an LCD screen, an LED display, an OLED display, an electrophoretic display, a computer monitor, a touchscreen, a television, etc., one or more speakers, and so on.

[0360] In some configurations, communications systems 1426 can include any suitable hardware, firmware, and / or software for communicating information to computing device 1350 (and, in some configurations, over communication network 1354 and / or any other suitable communication networks). For example, communications systems 1426 can include one or more transceivers, one or more communication chips and / or chip sets, and so on. In a more particular example, communications systems 1426 can include hardware, firmware, and / or software that can be used to establish a wired connection using any suitable port and / or communication standard (e.g., VGA, DVI video, USB, RS-232, etc.), Wi-Fi connection, a Bluetooth connection, a cellular connection, an Ethernet connection, and so on.

[0361] In some configurations, memory 1428 can include any suitable storage device or devices that can be used to store instructions, values, data, or the like, that can be used, for example, by processor 1422 to control the one or more data acquisition systems 1424, and / or receive data from the one or more data acquisition systems 1424; to generate images or plots from data; present content (e.g., data, images, a user interface) using a display; communicate with one or more computing devices 1350; and so on. Memory 1428 can include any suitable volatile memory, non-volatile memory, storage,-81- QB\920171.00672\100158611.4Client Ref. UMN 2025-119or any suitable combination thereof. For example, memory 1428 can include RAM, ROM, EPROM, EEPROM, other types of volatile memory, other types of non-volatile memory, one or more types of semi-volatile memory, one or more flash drives, one or more hard disks, one or more solid state drives, one or more optical drives, and so on.

[0362] In some configurations, any suitable computer-readable media can be used for storing instructions for performing the functions and / or processes described herein. For example, in some configurations, computer-readable media can be transitory or non-transitory. For example, non-transitory computer-readable media can include media such as magnetic media (e.g., hard disks, floppy disks), optical media (e.g., compact discs, digital video discs, Blu-ray discs), semiconductor media (e.g., RAM, flash memory, EPROM, EEPROM), any suitable media that is not fleeting or devoid of any semblance of permanence during transmission, and / or any suitable tangible media. As another example, transitory computer-readable media can include signals on networks, in wires, conductors, optical fibers, circuits, or any suitable media that is fleeting and devoid of any semblance of permanence during transmission, and / or any suitable intangible media.

[0363] As used herein in the context of computer implementation, unless otherwise specified or limited, the terms "component," "system," "module," "controller," "framework," and the like are intended to encompass part or all of computer-related systems that include hardware, software, a combination of hardware and software, or software in execution. For example, a component may be, but is not limited to being, a processor device, a process being executed (or executable) by a processor device, an object, an executable, a thread of execution, a computer program, or a computer. By way of illustration, both an application running on a computer and the computer can be a component. One or more components (or system, module, and so on) may reside within a process or thread of execution, may be localized on one computer, may be distributed -82- QB\920171.00672\100158611.4Client Ref. UMN 2025-119between two or more computers or other processor devices, or may be included within another component (or system, module, and so on).

[0364] In some implementations, devices or systems disclosed herein can be utilized or installed using methods embodying aspects of the disclosure. Correspondingly, description herein of particular features, capabilities, or intended purposes of a device or system is generally intended to inherently include disclosure of a method of using such features for the intended purposes, a method of implementing such capabilities, and a method of installing disclosed (or otherwise known) components to support these purposes or capabilities. Similarly, unless otherwise indicated or limited, discussion herein of any method of manufacturing or using a particular device or system, including installing the device or system, is intended to inherently include disclosure, as embodiments of the disclosure, of the utilized features and implemented capabilities of such device or system.

[0365] As used herein, the phrase "at least one of A, B, and C" means at least one of A, at least one of B, and / or at least one of C, or any one of A, B, or C or combination of A, B, or C. A, B, and C are elements of a list, and A, B, and C may be anything contained in the Specification.

[0366] The present disclosure has described one or more preferred embodiments, and it should be appreciated that many equivalents, alternatives, variations, and modifications, aside from those expressly stated, are possible and within the scope of the invention.-83- QB\920171.00672\100158611.4

Claims

Client Ref. UMN 2025-119CLAIMSWhat is claimed is:

1. A system for monitoring a health status of a patient, the system comprising: one or more radar sensors configured to be placed in an environment containing a patient; anda processor configured to:control the one or more radar sensors to emit radio waves into the environment; measure reflection data comprising reflected radio waves reflected by the environment;process the reflection data to determine motion state data, the motion state data characterizing a position and velocity for each datapoint of the reflection data;process the motion state data to isolate motion state data associated with human movement patterns to generate tracked motion state data;aggregate the tracked motion state data to generate aggregate motion data; process the aggregate motion data to determine a health status of the patient; andgenerate a report based on the health status of the patient.

2. The system of claim 1, wherein the aggregate motion data characterize at least one of a summarized height metric that describes a z-coordinate of the tracked motion state data, a summarized position metric that describes a position of the tracked motion state data, a summarized velocity metric that describes a change of position of the tracked motion state data in time, a summarized acceleration metric that describes a change of velocity of the tracked motion state data in time, a summarized derivative metric that describes a temporal derivative of position of the tracked motion state data in time, or an aggregate activity data.

3. The system of claim 2, wherein processing the aggregate motion data to determine the health status of the patient comprises applying a machine learning algorithm that identifies a fall of the patient according to at least one of the summarized-84- QB\920171.00672\100158611.4Client Ref. UMN 2025-119height metric, the summarized position metric, the summarized velocity metric, the summarized acceleration metric, or the summarized derivative metric through time.

4. The system of claim 2, wherein processing the aggregate motion data to determine the health status of the patient comprises applying a machine learning algorithm that identifies a behavior of the patient according to the summarized height metric through time, the behavior comprising one of sitting, sleeping, walking, or being on the floor.

5. The system of claim 2, wherein the processor is further configured to transmit the aggregate motion data to a memory configured to store the aggregate activity data longitudinally over time.

6. The system of claim 2, wherein processing the aggregate motion data to determine the health status of the patient comprises tracking the aggregate motion data longitudinally and applying a machine learning algorithm that characterizes a status of at least one of Alzheimer's disease, dementia, Alzheimer's disease related dementia, Parkinson's disease, or fall risk of the patient according to a longitudinal change in the aggregate activity data.

7. The system of claim 2, wherein the aggregate motion data further characterize a measurement time; and wherein processing the aggregate motion data to determine the health status of the patient comprises tracking the aggregate motion data longitudinally and applying a machine learning algorithm that characterizes a status of sundowning based on a longitudinal change in the time-dependent aggregate activity data.

8. The system of claim 2, wherein processing the motion state data to isolate motion state data associated with human movement patterns comprises applying density-based clustering algorithms to the motion state data.

9. The system of claim 2, wherein processing the motion state data to isolate motion state data associated with human movement patterns comprises applying a-85- QB\920171.00672\100158611.4Client Ref. UMN 2025-119trained convolutional neural network based on a micro-Doppler signature of the reflection data.

10. The system of claim 2, wherein processing the motion state data to isolate motion state data associated with human movement patterns comprises filtering the motion state data to discard at least one of motion state data with low signal to noise ratio or motion state data associated with static velocities.

11. The system of claim 2, wherein aggregating the tracked motion state data comprises applying statistical methods to determine the summarized height metric that describes the z-coordinate of the tracked motion state data and discarding associated x-and y-coordinates of the tracked motion state data.

12. The system of claim 11, wherein aggregating the tracked motion state data further comprises discarding velocities associated with the tracked motion state data.

13. The system of claim 2, wherein aggregating the tracked motion state data comprises summing a number of tracked motion state data points in each frame to characterize the aggregate activity data.

14. The system of claim 2, wherein the one or more radar sensors comprise a plurality of radar sensors arranged in an array, and wherein the reflection data comprise reflected radio waves measured by a combination of at least two of the plurality of radar sensors.

15. The system of claim 2, wherein the radio waves emitted by the radar sensors are frequency modulated continuous waves.

16. The system of claim 15, wherein the radio waves have a frequency modulated pattern characterized by a chirp.-86- QB\920171.00672\100158611.4Client Ref. UMN 2025-11917. A method for monitoring a health status of a patient, the method comprising steps of:placing one or more radar sensors in an environment containing a patient; and using a processor to:control the one or more radar sensors to emit radio waves into the environment;measure reflection data comprising reflected radio waves reflected by the environment;process the reflection data to determine motion state data, the motion state data characterizing a position and velocity for each datapoint of the reflection data;process the motion state data to isolate motion state data associated with human movement patterns to generate tracked motion state data;aggregate the tracked motion state data to generate aggregate motion data;process the aggregate motion data to determine a health status of the patient; andgenerate a report based on the health status of the patient.

18. The method of claim 17, wherein the aggregate motion data characterize at least one of a summarized height metric that describes a z-coordinate of the tracked motion state data, a summarized position metric that describes a position of the tracked motion state data, a summarized velocity metric that describes a change of position of the tracked motion state data in time, a summarized acceleration metric that describes a change of velocity of the tracked motion state data in time, a summarized derivative metric that describes a temporal derivative of position of the tracked motion state data in time, or an aggregate activity data.

19. The method of claim 18, wherein processing the aggregate motion data to determine the health status of the patient comprises applying a machine learning algorithm that identifies a fall of the patient according to at least one of the summarized height metric, the summarized position metric, the summarized velocity metric, the summarized acceleration metric, or the summarized derivative metric through time.-87- QB\920171.00672\100158611.4Client Ref. UMN 2025-11920. The method of claim 18, wherein processing the aggregate motion data to determine the health status of the patient comprises applying a machine learning algorithm that identifies a behavior of the patient according to the summarized height metric through time, the behavior comprising one of sitting, sleeping, walking, or being on the floor.

21. The method of claim 18, wherein the processor is further configured to transmit the aggregate motion data to a memory configured to store the aggregate activity data longitudinally over time.

22. The method of claim 18, wherein processing the aggregate motion data to determine the health status of the patient comprises tracking the aggregate motion data longitudinally and applying a machine learning algorithm that characterizes a status of at least one of Alzheimer's disease, dementia, Alzheimer's disease related dementia, Parkinson's disease, or fall risk of the patient according to a longitudinal change in the aggregate activity data.

23. The method of claim 18, wherein the aggregate motion data further characterize a measurement time; and wherein processing the aggregate motion data to determine the health status of the patient comprises tracking the aggregate motion data longitudinally and applying a machine learning algorithm that characterizes a status of sundowning based on a longitudinal change in the time-dependent aggregate activity data.

24. A method for monitoring a health status of a patient, the method comprising steps of:placing one or more radar sensors in an environment containing a patient; and using a processor to:control the one or more radar sensors to emit radio waves into the environment;measure reflection data comprising reflected radio waves reflected by the environment;-88- QB\920171.00672\100158611.4Client Ref. UMN 2025-119process the reflection data to determine motion state data, the motion state data characterizing a position and velocity for each datapoint of the reflection data;process the motion state data to generate micro-Doppler analysis data that characterize a micro-Doppler signature of the motion state data;process the micro-Doppler analysis data to determine vital sign data of the patient that characterizes at least one of a respiratory rate or pulse rate of the patient; andgenerate a report based on the vital sign data of the patient.

25. The method of claim 24, wherein the patient is an infant; wherein the method further comprises using the processor to process the vital sign data to determine a risk level of sudden infant death syndrome; and wherein the report is further based on the determined risk level.-89- QB\920171.00672\100158611.4

Images