Field of the Disclosure

[0001] The present disclosure is directed generally to methods and systems for analyzing a patient’s mobility using a mobility analysis system.

Background

[0002] Hospital stays are very expensive and should not be unnecessarily prolonged. Hospital staff consistently has to make a tradeoff between the cost of a prolonged stay in the ward versus the risk of premature discharge and costs of readmission. Both Length of Stay and Readmissions are important KPI’s for hospitals to track as suboptimal outcomes are linked to relatively high costs. Discharge Readiness Scores (DRS) help in making these decisions more objective. For example, for joint replacement surgeries such as knee or hip replacement, it is obvious that mobility is a key element for discharge readiness, among other discharge readiness elements. However, mobility and ability for self-care, for example Activities of Daily Living (ADL), are important but not objectively measured for these or any other patients.

[0003] There are many common barriers that prevent patient discharge. For example, clinical barriers include unstable physiological conditions such as unstable vitals, abnormal lab readings, or further complications. Patient self-care and independence barriers include situations where the patient is not ready to perform ADLs (e.g., eating, using the toilet, showering, climbing stairs, etc.) upon discharge. Logistical or operational/administrative barriers include incomplete documentation, unclear discharge disposition, unavailable medication, and other scenarios.

[0004] Unfortunately, it is difficult and time consuming to have sufficiently accurate insights into a patient’s mobility and their capability for self-care to inform the discharge process. Healthcare professionals are not able to observe the patient at all times and current mobility monitors, such as activity monitors, are only able to measure relative movements and are not measuring the patient’s ability for self-care and independence. The lack of sufficient data on self- care and independence is a problem for hospitals as well as rehabilitation centers and skilled nursing facilities. [0005] In addition, while physical activity has been proven to accelerate hospital discharge, patients are not always actively encouraged to take up self-care activities because the healthcare professional does not have a clear understanding of the physical abilities of the patient. This can lead to situations where the healthcare professional is providing unnecessary support to the patient, which does not make efficient use of the healthcare professional’s time and does not increase the patient’s mobility and functional independence.

Summary of the Disclosure

[0006] Accordingly, there is a continued need for methods and systems that objectively analyze a patient’s mobility and functional capabilities. Various embodiments and implementations herein are directed to a method and system configured to generate and present a healthcare recommendation for a patient based on the patient’s objectively determined mobility level. The system receives information about a patient from a sensor of the system in a patient setting, where the sensor information comprises information about the patient’s mobility. The system also receives a floor plan or other structural information about the patient’s setting. The system then extracts one or more mobility features about the patient from the received sensor signal, and analyzes the extracted mobility features in view of the received floor plan or other structural information about the patient’s setting to generate a mobility analysis for the patient. The generated mobility analysis comprises information about the patient’s ability to perform a plurality of mobility tasks. The system compares this generated mobility analysis to predetermined patient mobility task list and determines a mobility achievement level of the patient. A healthcare recommendation is generated for the patient based on the determined mobility achievement level, and the system reports the healthcare recommendation via a user interface.

[0007] Generally, in one aspect, a method for analyzing a patient’s mobility using a mobility analysis system is provided. The method includes: (i) receiving, from a sensor of the mobility analysis system, a sensor signal comprising information about the patient’s mobility; (ii) receiving, by the mobility analysis system, a floor plan or other structural information about the patient’s setting; (iii) extracting, from the received sensor signal, one or more mobility features about the patient; (iv) analyzing the one or more extracted mobility features in view of the received floor plan or other structural information about the patient’s setting to generate a mobility analysis for the patient, wherein the generated mobility analysis comprises information about the patient’s ability to perform a plurality of mobility tasks; (v) comparing, using a rule-based comparison, the generated mobility analysis to a predetermined patient mobility task list; (vi) determining, based on the comparison, a mobility achievement level of the patient; (vii) generating, based on the determined mobility achievement level, a healthcare recommendation for the patient, wherein the healthcare recommendation comprises a discharge recommendation or a treatment intervention recommendation; and (viii) reporting the healthcare recommendation to a user via a user interface of the mobility analysis system.

[0008] According to an embodiment, the method further includes implementing the provided healthcare recommendation.

[0009] According to an embodiment, the sensor is worn by the patient. According to an embodiment, the sensor is positioned within the patient’s room in the setting. According to an embodiment, the sensor comprises one or more of an accelerometer, a GPS sensor, and a camera.

[0010] According to an embodiment, the method further includes: (i) tracking the patient after the healthcare recommendation is implemented; (ii) determining, based on said tracking, whether the healthcare recommendation was properly made by the mobility analysis system; (iii) training the mobility analysis system based on said determination.

[0011] According to an embodiment, the treatment intervention recommendation comprises a mobility recommendation derived from the patient’s determined mobility achievement level.

[0012] According to an embodiment, the discharge recommendation comprises a discharge decision derived from the patient’s determined mobility achievement level.

[0013] According to a second aspect is a system for analyzing a patient’s mobility. The system includes: a patient sensor configured to generate a sensor signal comprising information about a patient’s mobility setting; a floor plan or other structural information about the patient’s setting; a processor configured to: (i) extract, from the sensor signal, one or more mobility features about the patient; (ii) analyze the one or more extracted mobility features in view of the received floor plan or other structural information about the patient’s setting to generate a mobility analysis for the patient, wherein the generated mobility analysis comprises information about the patient’s ability to perform a plurality of mobility tasks; (iii) compare, using a rule-based comparison, the generated mobility analysis to a predetermined patient mobility task list; (iv) determine, based on the comparison, a mobility achievement level of the patient (v) generate, based on the determined mobility achievement level, a healthcare recommendation for the patient, wherein the healthcare recommendation comprises a discharge recommendation or a treatment intervention recommendation; and a user interface configured to provide the generated healthcare recommendation to a user.

[0014] It should be appreciated that all combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are contemplated as being part of the inventive subject matter disclosed herein. It should also be appreciated that terminology explicitly employed herein that also may appear in any disclosure incorporated by reference should be accorded a meaning most consistent with the particular concepts disclosed herein.

[0015] These and other aspects of the various embodiments will be apparent from and elucidated with reference to the embodiment(s) described hereinafter.

Brief Description of the Drawings

[0016] In the drawings, like reference characters generally refer to the same parts throughout the different views. The figures showing features and ways of implementing various embodiments and are not to be construed as being limiting to other possible embodiments falling within the scope of the attached claims. Also, the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the various embodiments.

[0017] FIG. 1 is a flowchart of a method for analyzing a patient’s mobility, in accordance with an embodiment.

[0018] FIG. 2 is a schematic representation of a mobility analysis system, in accordance with an embodiment.

[0019] FIG. 3 is a flowchart of a method for analyzing a patient’s mobility, in accordance with an embodiment. [0020] FIG. 4 is a flowchart of a method for analyzing a patient’s mobility, in accordance with an embodiment.

Detailed Description of Embodiments

[0021] The present disclosure describes various embodiments of a system and method configured to generate and present a healthcare recommendation for a patient. More generally, Applicant has recognized and appreciated that it would be beneficial to provide a method and system to facilitate discharge decisions. Accordingly, a mobility analysis system receives information about a patient from a sensor of the system in a patient setting, where the sensor information comprises information about the patient’s mobility. The system also receives a floor plan or other structural information about the patient’s setting. The system then extracts one or more mobility features about the patient from the received sensor signal, and analyzes the extracted mobility features in view of the received floor plan or other structural information about the patient’s setting to generate a mobility analysis for the patient. The generated mobility analysis comprises information about the patient’s ability to perform a plurality of mobility tasks. The system compares this generated mobility analysis to predetermined patient mobility task list and determines a mobility achievement level of the patient. A healthcare recommendation is generated for the patient based on the determined mobility achievement level, and the system reports the healthcare recommendation via a user interface. The healthcare recommendation can then be implemented by a healthcare professional or by the in-patient healthcare setting.

[0022] According to an embodiment, the systems and methods described or otherwise envisioned herein can, in some non-limiting embodiments, be implemented as an element for a commercial product for patient analysis or monitoring, such as the Philips® Patient Flow Capacity Suite (PFCS) (available from Koninklijke Philips NV, the Netherlands), or any suitable patient or care facility system.

[0023] Referring to FIG. 1 , in one embodiment is a flowchart of a method 100 for analyzing a patient’s mobility using a mobility analysis system. The methods described in connection with the figures are provided as examples only, and shall be understood not limit the scope of the disclosure. The mobility analysis system can be any of the systems described or otherwise envisioned herein. The mobility analysis system can be a single system or multiple different systems. [0024] At step 110 of the method, a mobility analysis system is provided. Referring to an embodiment of a mobility analysis system 200 as depicted in FIG. 2, for example, the system comprises one or more of a processor 220, memory 230, user interface 240, communications interface 250, and storage 260, interconnected via one or more system buses 212. It will be understood that FIG. 2 constitutes, in some respects, an abstraction and that the actual organization of the components of the system 200 may be different and more complex than illustrated. Additionally, mobility analysis system 200 can be any of the systems described or otherwise envisioned herein. Other elements and components of mobility analysis system 200 are disclosed and/or envisioned elsewhere herein.

[0025] At step 120 of the method, the mobility analysis system receives information about a patient for which a mobility analysis will be performed. The patient for which the system performs the mobility analysis is an in-patient individual at a healthcare facility such as a long-term care facility, nursing care facility, hospital, urgent care, or any other healthcare facility. According to an embodiment, the received patient information comprises, for example, demographic and/or medical features about the patient. For example, demographic information or features may comprise age, gender, past healthcare facility visits or admissions, and other demographic information. Medical information or features may comprise vital sign information about the patient, including but not limited to physiologic vital signs such as heart rate, blood pressure, respiratory rate, apnea, SpCh, invasive arterial pressure, noninvasive blood pressure, physiological measurements other than vital data such as physical observations, patient diagnosis or medication condition such as cardiac disease, psychological disorders, chronic obstructive pulmonary disease, and more, among many other types of medical information. Many other types of patient information are possible, including but not limited to patient independence data. Accordingly, the received information can be any information relevant to a patient mobility analysis.

[0026] The mobility analysis system can receive patient information from a variety of different sources. According to an embodiment, the mobility analysis system is in communication with an electronic medical records database from which the patient information and one or more of the plurality of features may be obtained or received. According to an embodiment, the mobility analysis system comprises an electronic medical record database or system 270 which is optionally in direct and/or indirect communication with system 200. According to another embodiment, the patient mobility analysis system may obtain or receive the information from equipment or a healthcare professional obtaining that information directly from the patient.

[0027] The patient information received by the patient mobility analysis system may be processed by the system according to methods for data handling and processing/preparation, including but not limited to the methods described or otherwise envisioned herein. The patient information received by the patient mobility analysis system may be utilized, before or after processing, immediately or may be stored in local or remote storage for use in further steps of the method.

[0028] Also at step 120 of the method, the mobility analysis system receives sensor data comprising information about the patient’s mobility. Accordingly, the patient mobility analysis system comprises one or more patient sensors 280 which are configured to obtain or otherwise receive sensor data comprising information about the patient’s mobility. For example, system 200 can be in direct and/or indirect communication with the one or more patient sensors 280, which may be remote or local to one or more other components of system 200. The sensor information may be from a single sensor, or may be data from multiple different sensors, including multiple sensors of a single type or sensors of two or more different types.

[0029] The sensor 280 may be any sensor capable of generating or obtaining sensor data that includes information about the patient’s mobility. According to an embodiment, the sensor may be worn by the patient. According to another embodiment, the sensor may be positioned within the patient’s room in the healthcare setting. As a few non-limiting examples of a mobility sensor, the sensor may be a movement sensor such as an accelerometer, gyroscope, or other motion sensor, a location tracking system, a GPS sensor, a camera, a passive infrared sensor, an audio sensor, and/or any other sensor type capable of obtaining or receiving data that can be indicative of any aspect of mobility. According to an embodiment, a movement sensor obtains information about the patient’s body position, motion, and/or location. For example, an accelerometer can be attached to the patient, and can detect motion and change in position, such as lying, sitting, or standing and walking gait. The movement sensor can be worn on the patients’ body or localized within the room.

[0030] The sensor signal comprising information about the patient’s mobility received by the patient mobility analysis system may be processed by the system according to methods for data handling and processing/preparation, including but not limited to the methods described or otherwise envisioned herein. The sensor information received by the patient mobility analysis system may be utilized, before or after processing, immediately or may be stored in local or remote storage for use in further steps of the method.

[0031] At step 130 of the method, the mobility analysis system receives or accesses a floor plan or other structural information about the patient’s setting. The floor plan or other structural information about the setting, such as the setup or design of the patient’s room or equipment in the room, can be obtained from any source. For example, the system may comprise or have access to a database of information about the healthcare setting such as floor plans, room plans, equipment plans, and other information. According to an embodiment, in order to link the patient location and specific ADLs, it is important to know the floorplan of the room or ward and to mark the functional areas and locations, for example bed, couch, bathroom, toilet, shower, or sink. As most hospitals have a generic and repetitive room layout this can be extracted from architecture plans. According to an embodiment, this is done automatically and can be Al-driven as the icons are very common and universal and will be used repetitively. The retrieved or received floor plan or other structural information about the patient’s healthcare setting may be utilized, before or after processing, immediately or may be stored in local or remote storage for use in further steps of the method.

[0032] At optional step 132 of the method, the mobility analysis system receives or accesses a dataset, or a database comprising such a dataset, of historical data. The historical data comprises information about prior patients, including diagnoses, test results, mobility test results, mobility progression, discharge information, readmission information, and/or any other information that may be useful from a historical data viewpoint. The historical data can be analyzed to identify patients identical or similar to a current patient, and can be utilized for many different aspects of the mobility system. For example, the system may utilize historical data to generate a mobility analysis for the patient as described in step 140 of the method, including using the data to generate information about the patient’s ability to perform one or more Activities of Daily Living (ADL), such as self-care activities among many other activities, compared to similar historical patients. As another example, the system may utilize historical data to calculate and/or display patient progress or speed of progress to predict future ability. For example, the system may compare the patient to historical data such as similar patients, and utilize that comparison to generate a timeframe for likely or possible discharge. The system might also be able to predict or recommend when a patient will be able to perform a certain mobility task in a certain way (e.g., independent or with support) based on historic data, so that care events can be better planned to prevent queueing and delays. Many other uses of historical data are possible.

[0033] At step 140 of the method, the mobility analysis system extracts one or more mobility features about the patient from the sensor signal received in step 120 of the method. The features can be any of the mobility features described or otherwise envisioned herein. The system can be trained to identify and extract the mobility features from the received patient information, using any of a wide variety of algorithms, methods, or systems for identifying and extracting mobility data. The plurality of identified and extracted mobility features may be utilized immediately or may be stored in local or remote storage for use in further steps of the method. According to an embodiment, the patient mobility features may undergo data processing at any stage.

[0034] At step 150 of the method, the patient mobility system analyzes the one or more extracted mobility features in view of the received floor plan or other structural information about the patient’s healthcare setting. This analysis results in the generation of a mobility analysis for the patient, comprising information about the patient’s ability to perform a plurality of mobility tasks. According to an embodiment, the mobility analysis comprises information about the patient’s ability to perform one or more Activities of Daily Living (ADL), such as self-care activities among many other activities. Some of the possible mobility tasks include but are not limited to:

[0035] 1. Bed mobility, namely ability to change position in bed. This can include rolling in bed, supine movements including lying-to-sit and sit-to-lying, and movements such as sit-to-stand and stand-to-sit, among other movements.

[0036] 2. Transferring mobility, namely walking inside or outside of the healthcare room. This can include initial standing balance, use of assistive device, right and left stepping during gait, walking distance, gait speed, ascending and descending stairs, and turning 180° and return, among other movements.

[0037] 3. Ability to perform other ADLs. This can include using the toilet (location: toilet, position: sitting or standing), taking a shower in a sitting position (location: shower, position: sitting), taking a shower in a standing position (location: shower, position: standing), washing hands or brushing teeth (location: sink, position: standing or sitting), and sitting in a chair or on a couch (location: chair or couch, position: sitting), among other movements or positions.

[0038] At step 160 of the method, the system compares the generated mobility analysis to a predetermined patient mobility task list. This can be, for example, a rule-based comparison. According to an embodiment, the predetermined patient mobility task list is a list of mobility tasks that a patient might or should be capable of performing. The mobility task list may be specific to a patient, such that a patient much be or should be capable of performing all of the tasks in the mobility task list. The mobility task list may be specific to an event, for example before discharge, before moving to a subsequent ward (e.g., ICU to a general ward), before surgery, and/or before another medical procedure/event (e.g., order a wheelchair for patient x as soon as y occurs, etc.). Alternatively, the mobility task list may be generic such that it is a list of all possible mobility tasks that might be utilized by the system. The mobility tasks can be any of the tasks described or otherwise envisioned herein. The mobility tasks in the predetermined patient mobility task list can be automatically generated, can be created by a healthcare professional, can be curated by a healthcare professional, or can otherwise be created. The predetermined patient mobility task list can be stored in local or remote storage for use in the method and by the mobility analysis system.

[0039] At step 170 of the method, the system utilizes the results of the comparison in step 160 of the method to determine a mobility achievement level of the patient. This determined mobility achievement level of the patient may be, for example, a list of the mobility tasks that the patient is and/or is not capable of performing. The mobility achievement level may be a list, a percentage, a score, or other quantitative or qualitative result. For example, the generated mobility analysis may comprise a list of five mobility tasks that the patient is capable of performing, and five tasks that the patient is not capable of performing. The predetermined patient mobility task list comprises ten mobility tasks that the patient could be capable of performing, or is required to be capable of performing in order for a particular result. Based on a comparison of the generated mobility analysis and the predetermined patient mobility task list in step 160 of the method, the system in step 170 of the method creates the quantitative or qualitative result, i.e., the mobility achievement level of the patient. In this example, the determined mobility achievement level of the patient may be, for example, a percentage of 50%, a score of 0.5, or any other quantitative or qualitative result. According to another example, the determined mobility achievement level of the patient may comprise information about how stable the patient’s performance in a certain task is (e.g., the patient is able to consistently perform the task, or is better able to perform the task today than yesterday, and so on). The determined mobility achievement level of the patient may also include information identifying the specific tasks that the patient is and/or is not capable of performing. The determined mobility achievement level of the patient may be utilized immediately or may be stored in local or remote storage for use in further steps of the method.

[0040] According to an embodiment, the system can automatically assess the patient’s mobility and ability for self-care based on set targets such as activity and duration. Hospitals can set and track achievement goals, potentially customized towards different department, procedure, or individual patient characteristics. It can also include intermediate goals that highlight a patient’s progress and enable staff to make better predictions with regard to future abilities, speed of recovery, and discharge planning. For example, the system or user could compare patient recovery (such as speed and/or progress) data to historic data or recovery trends for similar patients to predict an expected discharge date or date range. Intermediate achievement goals might include tasks such as: sitting in bed for 10 minutes, sitting in a chair for five minutes, getting out of bed (sit-to-stand/wheelchair/walking aid), walking a short distance, using the toilet solo, walking to a nurses’ station in a corridor, and many other goals. It can also include final achievement goals such as walking stairs.

[0041] At step 180 of the method, the system generates a healthcare recommendation based on the determined mobility achievement level. According to an embodiment, the healthcare recommendation comprises a discharge recommendation or a treatment intervention recommendation. According to an embodiment, the healthcare recommendation results directly from the quantitative or qualitative result of the determined mobility achievement level, such as a threshold analysis or determination. For example, a determined mobility achievement level of 50% or 0.5 or above may result in a specific healthcare recommendation, while a determined mobility achievement level below 50% or 0.5 may result in a different healthcare recommendation. As another example, the determined mobility achievement level may undergo further analysis to result in the healthcare recommendation.

[0042] A treatment intervention recommendation may comprise, for example, any recommendation to initiate, continue, or stop a particular treatment. According to an embodiment, the treatment intervention recommendation is configured to address an issue in mobility identified by the system in this method. For example, hospital staff can better understand how to best support patients in their recovery and rehabilitation when they have an objective insight on patient mobility, independence in self-care activities, and the patient’s next target. These insights prevent nurses from intervening and performing tasks for the patient if the patient is able to do it on their own. In addition this approach will also help in determining the appropriate moment to start occupational therapy in order to shorten the patient’s hospital stay, as well as the type of therapy and/or goals for that therapy to achieve improved mobility or other goals.

[0043] A discharge recommendation may comprise, for example, any recommendation to discharge or not discharge the patient. According to an embodiment, the discharge recommendation is configured to inform the healthcare professional whether the patient has satisfied enough mobility requirements to be suitably discharged. According to an embodiment, having an objective measure of patient mobility and independence in self-care, makes it easier to predict progress and effectively plan for discharge. Closely tracking the ADL and patient self-care independence over time can also help in predicting the patient independence at discharge. This will provide insight into the need for post-discharge (mobility) support services and the appropriate discharge disposition. Mobility or self-care (ADLs) could also be an indicator for optimizing an ambulatory discharge readiness scoring. Indeed, if a patient is not ready for discharge there is an increased risk of readmission, which can be extremely costly.

[0044] At step 190 of the method, the mobility analysis system displays or otherwise provides the generated healthcare recommendation to a clinician or other user via a user interface. The display may also comprise information about the patient, the input features, the patient mobility analysis, the predetermined patient mobility task list, the mobility achievement level, and/or any other information. Any of the information may be communicated by wired and/or wireless communication to another device. For example, the system may communicate the information to a mobile phone, computer, laptop, wearable device, and/or any other device configured to allow display and/or other communication of the report. The user interface can be any device or system that allows information to be conveyed and/or received, and may include a display, a mouse, and/or a keyboard for receiving user commands. According to an embodiment, the mobility analysis system displays or otherwise provides the generated healthcare recommendation to the patient. This can help the patient understand and celebrate their progression, which could help motivate even faster recovery and improved mobility. For example, the system can display to the user what kind of exercises can be performed to improve mobility, including display of a video or text on a smartphone, tablet, monitor, or hospital screen for instructions, among other options. The system could also track the patient while doing these exercises for feedback to the user and/or to determine whether the patient is properly performing those exercises, or whether there is improvement. This information could also be relevant prior to the admission or procedure in order to measure and improve their condition, and after discharge to continue progress.

[0045] At optional step 192 of the method, a clinician or other decisionmaker utilizes the displayed generated healthcare recommendation for patient care decision-making. For example, the healthcare recommendation may comprise a recommendation to initiate, continue, or stop a particular treatment configured to address an issue in mobility identified by the system, and the clinician or other decisionmaker can implement that recommendation. Implementation can comprise a prescription, order, or other implementation. As another example, the healthcare recommendation may comprise a recommendation to discharge the patient, if sufficient mobility is detected. As another example, the healthcare recommendation may comprise a recommendation to increase the duration or frequency of OT/PT. For example, if the patient’s bed is needed but the patient is not expected to be ready for discharge due to a limitation in patient independence or mobility (e.g., because another patient needs the bed (bed planning) or because of limitation in length of stay from a reimbursement perspective), then the system can recommend that the duration and/or frequency of OT/PT be increased. Thus, implementation may comprise an order to discharge the patient. As another example, the healthcare recommendation may comprise a recommendation to delay or defer discharge, if insufficient mobility is detected. Thus, implementation may not comprise an order to discharge the patient, and may comprise instructions to facilitate eventual discharge. Many other implementations are possible. These recommendations, and their implementation, can be an attempt by the clinician to speed discharge of capable patients.

[0046] Referring to FIG. 3, in one embodiment, is a flowchart of a method 300 for analyzing a patient’s mobility using a mobility analysis system. The methods described in connection with the figures are provided as examples only, and shall be understood not limit the scope of the disclosure. The mobility analysis system can be any of the systems described or otherwise envisioned herein. The mobility analysis system can be a single system or multiple different systems. [0047] At step 310, the mobility analysis system tracks the patient after the healthcare recommendation is implemented at step 192 of method 100 in FIG. 1. Tracking the patient can comprise gathering or receiving information about the patient’s mobility, readmission, diagnosis, care, treatment, disease progression, health, and/or any other information about the patient. This information can be provided to the system from any source including an electronic health records database, any other remote or local database, a user interface, a sensor associated with the patient, and/or from any other source. The tracking information may be utilized immediately or may be stored in local or remote storage for use in further steps of the method.

[0048] At step 320 of the method, the system may determine or receive a determination of whether the healthcare recommendation was properly made by the mobility analysis system. According to an embodiment, this determination is based on some or all of the information received or obtained in step 310 of the method. For example, a patient may have been discharged based on a recommendation generated by the method in FIG. 1, and tracking information from step 310 of the method may determine that the patient was readmitted to the hospital within 30 days due to mobility issues. The system may thus determine or receive a determination that the healthcare recommendation to discharge the patient was improper as the patient was not sufficiently mobile. Alternatively, a patient may have been discharged based on a recommendation generated by the method in FIG. 1, and tracking information from step 310 of the method may determine that the patient was sufficiently mobile for at least 90 days after that discharge. The system may thus determine or receive a determination that the healthcare recommendation to discharge the patient was proper.

[0049] At step 330 of the method, the determination or receipt of a determination by the system that a healthcare recommendation was proper or improper can then be utilized to train the system. For example, the information can be used to update the rules, the predetermined patient mobility task list, or other information. Thus, when patients are tracked post discharge, the system’s discharge algorithms, using machine learning, can be optimized based on the mobility data and self-case data (during and post hospitalization) of readmitted patients.

[0050] According to an embodiment, the system may utilize information about the mobility of the patient prior to admission and/or prior to surgery or other procedure. Although this may be challenging in the case of an emergency admission or procedure, the information might be obtainable from health tracking data, prior admissions, or other sources. For planned admissions, patient mobility could be obtained prior to admission or the procedure. For example, mobility could be analyzed while they are in the waiting room or at home by having the patient perform certain movements or exercises, among many other options.

[0051] Referring to FIG. 4 is a schematic representation of a mobility analysis method 400. Method 400 may comprise any of the steps described or otherwise envisioned herein, and may utilize a mobility analysis system that comprises any of the components described or otherwise envisioned herein. According to an embodiment, the method and system comprises patient mobility and self-care sensor data 410, such as position data from an accelerometer, location data, and other mobility data. The method and system comprises a patient mobility and self-care interpretation 420 based on both the patient mobility and self-care sensor data 410 received by the system, as well as floor plan information received by the system. The method and system comprises a rule-based mobility and self-care assessment 430 based on the outcome of the patient mobility and self-care interpretation 420, and utilizing a rule-based or guideline-based analysis. The result of the rule-based mobility and self-care assessment 430 is then utilized by the method and system to generate a healthcare recommendation 440. The healthcare recommendation 440 may be an in-hospital intervention need such as needed support, additional physical therapy, and other in-hospital intervention. The healthcare recommendation 440 may be a discharge readiness decision, which can include post-discharge mobility and self-care support need in addition to the most appropriate discharge disposition. According to an embodiment, the method and system can track the patient after discharge, including a determination of whether the patient is readmitted or not readmitted to the healthcare facility. This tracking information can be fed back into the method and system at 450, such as via a machine learning algorithm, to adjust or refine the rule-based or guideline-based analysis, among other input points.

[0052] According to an embodiment, the mobility analysis system may comprise many other configurations. For example, the system may comprise or utilize localization information for informal caregivers in order to track how much support the patient may need with regard to their ADLs and tracking if functional independence improves over time. For example, it may be important to know how much support a patient needs for an ADL, such as whether the patient needs the support of one or two caregivers, what functions the caregivers will perform, and so on. The recommendations provided by the system can be based on this information as well. [0053] The system may also calculate and/or display patient progress or speed of progress to predict future ability, including but not limited to the use of historical data. For example, the system may compare the patient to historical data such as similar patients, and utilize that comparison to generate a timeframe for likely or possible discharge. The system may comprise or utilize localization information for patients to benefit other services, such as the ability to quickly localize a patient who is wandering around in the hospital due to an alarm or unmet care need. The system may hand-off mobility and self-case data when the patient is transferred to the next level of care making visible services, assistance, or equipment that might benefit the patient. The system may comprise or utilize pre-operative and/or post-operative mobility and self-care (ADL) data to get better insight for care in procedures and surgeries, which can also help when setting the proper personalized targets for the patient. The system may comprise or utilize the patient’s mobility during a specific self-care activity to provide relevant insights about the impact of the activity on the overall mobility and stability of the patient at that point in time (e.g., just after standing up the patient is a bit less stable, but after two steps is improving; or, distances of two meters are fine, but the patient gets unstable if the distance is longer or the walking path is not straight, among many other examples and possibilities). According to an embodiment, the system may comprise or utilize an assessment of objective mobility and self-care data that is extended or supplemented with staff observations or questions.

[0054] Accordingly, the systems and methods described or otherwise envisioned herein combine a data-driven algorithm and method to determine patient mobility and ability for self- care. The system continuously tracks patient mobility and ability for self-care during their stay, identifying trends that are communicated to the patient in order to increase their feeling of achievement, and to staff, so they can effectively plan the discharge and, when possible, fine-tune care needed to shorten length of stay. The system provides a continuous and accurate mobility and self-care monitor which enables a more objective, easy, and reliable assessment of patient’s current mobility and ability for self-care (ADLs). This supports hospital staff in improving the discharge process by reducing length of stay through effective in-hospital interventions. This provides enhanced awareness of patient mobility and ability for self-care and support only when needed. This reduces staff care levels resulting in higher staff efficiency, increases patient mobility and self-care levels leading to increased functional independence, and leads to proactive initiation of occupational and physical therapy support in the healthcare setting. The systems and methods described or otherwise envisioned herein can also reduce readmission risk through effective discharge planning combined with post-hospital interventions. The system promotes patient readiness and preparedness for discharge, can facilitate information about the need for mobility and self-care support and intervention post discharge, for example taxi, physical therapy, fall detection, stairlift or home visit nurse requirements. The system therefore facilitates decisions about the most appropriate discharge disposition.

[0055] Referring to FIG. 2 is a schematic representation of a mobility analysis system 200. System 200 may be any of the systems described or otherwise envisioned herein, and may comprise any of the components described or otherwise envisioned herein. It will be understood that FIG. 2 constitutes, in some respects, an abstraction and that the actual organization of the components of the system 200 may be different and more complex than illustrated.

[0056] According to an embodiment, system 200 comprises a processor 220 capable of executing instructions stored in memory 230 or storage 260 or otherwise processing data to, for example, perform one or more steps of the method. Processor 220 may be formed of one or multiple modules. Processor 220 may take any suitable form, including but not limited to a microprocessor, microcontroller, multiple microcontrollers, circuitry, field programmable gate array (FPGA), application-specific integrated circuit (ASIC), a single processor, or plural processors.

[0057] Memory 230 can take any suitable form, including a non-volatile memory and/or RAM. The memory 230 may include various memories such as, for example LI, L2, or L3 cache or system memory. As such, the memory 230 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read only memory (ROM), or other similar memory devices. The memory can store, among other things, an operating system. The RAM is used by the processor for the temporary storage of data. According to an embodiment, an operating system may contain code which, when executed by the processor, controls operation of one or more components of system 200. It will be apparent that, in embodiments where the processor implements one or more of the functions described herein in hardware, the software described as corresponding to such functionality in other embodiments may be omitted.

[0058] User interface 240 may include one or more devices for enabling communication with a user. The user interface can be any device or system that allows information to be conveyed and/or received, and may include a display, a mouse, and/or a keyboard for receiving user commands. In some embodiments, user interface 240 may include a command line interface or graphical user interface that may be presented to a remote terminal via communication interface 250. The user interface may be located with one or more other components of the system, or may located remote from the system and in communication via a wired and/or wireless communications network.

[0059] According to an embodiment, the user interface and settings are customized for a healthcare role or specific staff member. This can include, for example, the visualization of the dashboard as well as when and how they want to receive notifications. This can be customized in general or can be based on the type of treatment or for individual patients. As just one example, the system can be configured to send a notification to user A as soon as patient X is able to sit so that the user can order service Y. The system might also be able to predict or recommend when a patient will be able to perform a certain mobility task in a certain way (e.g., independent or with support) based on historic data for similar patients, so that care events can be better planned to prevent queueing and delays.

[0060] Communication interface 250 may include one or more devices for enabling communication with other hardware devices. For example, communication interface 250 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol. Additionally, communication interface 250 may implement a TCP/IP stack for communication according to the TCP/IP protocols. Various alternative or additional hardware or configurations for communication interface 250 will be apparent.

[0061] Storage 260 may include one or more machine-readable storage media such as readonly memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, or similar storage media. In various embodiments, storage 260 may store instructions for execution by processor 220 or data upon which processor 220 may operate. For example, storage 260 may store an operating system 261 for controlling various operations of system 200.

[0062] It will be apparent that various information described as stored in storage 260 may be additionally or alternatively stored in memory 230. In this respect, memory 230 may also be considered to constitute a storage device and storage 260 may be considered a memory. Various other arrangements will be apparent. Further, memory 230 and storage 260 may both be considered to be non-transitory machine-readable media. As used herein, the term non-transitory will be understood to exclude transitory signals but to include all forms of storage, including both volatile and non-volatile memories.

[0063] While system 200 is shown as including one of each described component, the various components may be duplicated in various embodiments. For example, processor 220 may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform steps or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where one or more components of system 200 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, processor 220 may include a first processor in a first server and a second processor in a second server. Many other variations and configurations are possible.

[0064] According to an embodiment, the electronic medical record system 270 is an electronic medical records database from which the information about the patient, including the mobility features, may be obtained or received. The electronic medical records database may be a local or remote database and is in direct and/or indirect communication with the mobility analysis system 200. Thus, according to an embodiment, the mobility analysis system comprises an electronic medical record database or system 270.

[0065] According to an embodiment, the system comprises one or more patient sensors 280. The patient sensor 280 may be any sensor capable of generating or obtaining sensor data that includes information about the patient’s mobility. According to an embodiment, the sensor may be worn by the patient. According to an embodiment, the sensor may be worn by the patient or positioned around the patient prior to admission, such that the system can obtain baseline data prior to admission or a procedure. Thus the sensor may be a sensor such as a smartphone or wearable of the user. According to another embodiment, the sensor may be positioned within the patient’s room in the healthcare setting. As a few non-limiting examples of a mobility sensor, the sensor may be a movement sensor such as an accelerometer, gyroscope, or other motion sensor, a location tracking system, a GPS sensor, a camera, a passive infrared sensor, an audio sensor, and/or any other sensor type capable of obtaining or receiving data that can be indicative of any aspect of mobility. According to an embodiment, a movement sensor obtains information about the patient’s body position, motion, and/or location. For example, an accelerometer can be attached to the patient, and can detect motion and change in position, such as lying, sitting, or standing and walking gait. The movement sensor can be worn on the patients’ body or localized within the room.

[0066] According to an embodiment, storage 260 of system 200 may store one or more algorithms, modules, and/or instructions to carry out one or more functions or steps of the methods described or otherwise envisioned herein. For example, the system may comprise, among other instructions or data, healthcare setting floor plan data 262, mobility tasks 263, and/or reporting instructions 264.

[0067] According to an embodiment, healthcare setting floor plan data 262 comprises a floor plan or other structural information about the patient’s healthcare setting. According to an embodiment, in order to link the patient location and specific ADLs, it is important to know the floorplan of the room or ward and to mark the functional areas and locations, for example bed, couch bathroom, toilet, shower, or sink. As most hospitals have a generic and repetitive room layout this can be extracted from architecture plans. According to an embodiment, this is done automatically and can be Al-driven as the icons are very common and universal and will be used repetitively. The retrieved or received floor plan or other structural information about the patient’s healthcare setting may be utilized, before or after processing, immediately or may be stored in local or remote storage for use in further steps of the method.

[0068] According to an embodiment, mobility tasks 263 is a list or other configuration of a plurality of possible mobility tasks. This may include, for example, the tasks such as Activities of Daily Living (ADL), including self-care activities among many other activities. Some of the possible mobility tasks are described or otherwise envisioned herein. The mobility tasks 263 may also comprise the predetermined patient mobility task list, which is a list of mobility tasks that a patient might or should be capable of performing. The mobility task list may be specific to a patient, such that a patient much be or should be capable of performing all of the tasks in the mobility task list. Alternatively, the mobility task list may be generic such that it is a list of all possible mobility tasks that might be utilized by the system. The mobility tasks can be any of the tasks described or otherwise envisioned herein. The mobility tasks 263 can be automatically generated, can be created by a healthcare professional, can be curated by a healthcare professional, or can otherwise be created.

[0069] According to an embodiment, reporting instructions 264 direct the mobility analysis system to generate and provide to a user via a user interface information comprising a generated healthcare recommendation. The display may also comprise information about the patient, the input features, the patient mobility analysis, the predetermined patient mobility task list, the mobility achievement level, and/or any other information. Any of the information may be communicated by wired and/or wireless communication to another device. For example, the system may communicate the information to a mobile phone, computer, laptop, wearable device, and/or any other device configured to allow display and/or other communication of the report. The user interface can be any device or system that allows information to be conveyed and/or received, and may include a display, a mouse, and/or a keyboard for receiving user commands.

[0070] According to an embodiment, the mobility analysis system is configured to process many thousands or millions of datapoints in the input data used to train the system, as well as to process and analyze the received plurality of mobility features. For example, generating a functional and skilled trained system using an automated process such as feature identification and extraction and subsequent training requires processing of millions of datapoints from input data and the generated features. This can require millions or billions of calculations to generate a novel trained system from those millions of datapoints and millions or billions of calculations. As a result, the trained system is novel and distinct based on the input data and parameters of the machine learning algorithm, and thus improves the functioning of the mobility analysis system. Thus, generating a functional and skilled trained system comprises a process with a volume of calculation and analysis that a human brain cannot accomplish in a lifetime, or multiple lifetimes. By providing an improved mobility analysis, this novel patient mobility analysis system has an enormous positive effect on patient care and discharge compared to prior art system.

[0071] All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and/or ordinary meanings of the defined terms.

[0072] The indefinite articles “a” and “an,” as used herein in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean “at least one.” [0073] The phrase “and/or,” as used herein in the specification and in the claims, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and/or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and/or” clause, whether related or unrelated to those elements specifically identified.

[0074] As used herein in the specification and in the claims, “or” should be understood to have the same meaning as “and/or” as defined above. For example, when separating items in a list, “or” or “and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of’ or “exactly one of,” or, when used in the claims, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of.”

[0075] As used herein in the specification and in the claims, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified.

[0076] It should also be understood that, unless clearly indicated to the contrary, in any methods claimed herein that include more than one step or act, the order of the steps or acts of the method is not necessarily limited to the order in which the steps or acts of the method are recited.

[0077] In the claims, as well as in the specification above, all transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “composed of,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of’ and “consisting essentially of’ shall be closed or semi-closed transitional phrases, respectively.

[0078] While several inventive embodiments have been described and illustrated herein, those of ordinary skill in the art will readily envision a variety of other means and/or structures for performing the function and/or obtaining the results and/or one or more of the advantages described herein, and each of such variations and/or modifications is deemed to be within the scope of the inventive embodiments described herein. More generally, those skilled in the art will readily appreciate that all parameters, dimensions, materials, and configurations described herein are meant to be exemplary and that the actual parameters, dimensions, materials, and/or configurations will depend upon the specific application or applications for which the inventive teachings is/are used. Those skilled in the art will recognize, or be able to ascertain using no more than routine experimentation, many equivalents to the specific inventive embodiments described herein. It is, therefore, to be understood that the foregoing embodiments are presented by way of example only and that, within the scope of the appended claims and equivalents thereto, inventive embodiments may be practiced otherwise than as specifically described and claimed. Inventive embodiments of the present disclosure are directed to each individual feature, system, article, material, kit, and/or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and/or methods, if such features, systems, articles, materials, kits, and/or methods are not mutually inconsistent, is included within the inventive scope of the present disclosure.