Respiratory care system

Abstract

Described in this specification are technologies, including systems and methods, for medical devices for respiratory therapy. The technologies include systems and methods to control (interactively) one or more respiratory care devices, e.g., for high-flow therapy. The technologies described in this specification can be used in a hospital or home care setting and provide a user with means for monitoring and / or adjusting respiratory therapies.

Description

RESPIRATORY CARE SYSTEMCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of and priority to U.S. provisional application No. 63 / 522,874, filed on June 23, 2023, and entitled “Respiratory Care System with Digital Health Tools,” the contents of which are hereby incorporated herein by reference in their entirety.BACKGROUND

[0002] Respiratory distress can impact patients in a wide variety of ways, from a number of causes, and with indications that can range from mild, to moderate and severe. In some situations, respiratory distress arises from progression of typical asthma or temporary airway impairment, in other cases from hereditary sources, or the result of ongoing environmental exposure, or the consequence of non-pulmonary diseases. Chronic obstructive pulmonary disease (COPD) is a major contributor to respiratory distress as it can cause chronic airflow limitations through inflammation, changes in the small airways or parenchymal destruction. The elasticity of the lung can be decreased, which can inhibit the ability of the lungs to extend and distend during breathing. The actual portion of the lung responsible for gas transport (of oxygen and carbon dioxide) can also be damaged, with substantial reduction in the efficacy of breathing. As a result, a patient can suffer numerous harmful indications, which can increase in severity as the condition worsens. Hypercapnia and hypoxemia are common clinical signs of acute or chronic respiratory conditions, and shortness of breath (dyspnea) is a common symptom of these conditions. Given the rising costs of healthcare, the patients with severe conditions can have a particularly high burden on the healthcare system, particularly if there is a long-term care need.SUMMARY

[0003] Described in this specification are technologies, including systems and methods, for medical devices for respiratory therapy. The technologies include systems and methods to control (interactively) one or more respiratory care devices, e.g., for high-flow therapy, e.g., as described in PCT publication No. WO2021 / 183817, titled “High velocity respiratory therapy unit with non-contact sensing and control,” which is incorporated herein by reference in its entirety. The technologies described in this specification can be used in a hospital orhome care setting and provide a user with means for monitoring and / or adjusting respiratory therapies.

[0004] In an aspect, the technologies described in this specification include systems and methods for controlling a medical device for respiratory care. The technologies include systems and methods for: receiving, by a processor of a medical device, from one or more processors of one or more respiratory care devices, a plurality of data sets, each data set corresponding to a current alarm; querying, by the processor, a database comprising one or more a priority values, each priority value corresponding to at least one alarm; assigning, by the processor, a priority value to each received alarm; and displaying, on a graphical user interface (GUI), the alarms in order of priority.

[0005] In an aspect, the technologies described in this specification include systems and methods for controlling a medical device for respiratory care. The technologies include systems and methods for: receiving, by a processor of a medical device, one or more data sets, each data set comprising setting values for operating a respiratory care device; transmitting, by the processor of the medical device, to one or more processors of one or more respiratory care devices, the one or more data sets; updating, by the one or more processors of one or more respiratory care devices, the settings of the one or more respiratory care devices, and delivering, by the one or more respiratory care devices, a breathing gas to a patient under updated operating conditions based on the received setting values.

[0006] In an aspect, the technologies described in this specification include systems and methods for controlling a medical device for respiratory care. The technologies include systems and methods for: receiving, by a processor of a medical device, from one or more processors of one or more respiratory care devices, data comprising respiratory care device operation information and, from one or more processors of patient device, patient data comprising symptom information, and displaying, on a graphical user interface (GUI), the operation information and symptom information.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The foregoing and other objects and advantages will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:

[0008] Fig. 1 is a diagram illustrating an example system architecture for a networked system for respiratory care as described in this specification;

[0009] Fig. 2 is a diagram illustrating an example cloud system (e.g., an example alarm notification system) for a networked system for respiratory care as described in this specification;

[0010] Fig. 3A is an example GUI of a Patient App (alarms display indicated by dashed box) and Fig. 3B is an example GUI of a Caregiver App (alarms display indicated by dashed box) of an alarm system for a networked system for respiratory care as described in this specification;

[0011] Fig. 4A is an example GUI for multiple alarm prioritization and Fig. 4B is an example GUI displaying alarm details for a networked system for respiratory care as described in this specification;

[0012] Fig. 5 is an example GUI of a Provider App displaying alarm prioritization (alarms display indicated by dashed box) for a networked system for respiratory care as described in this specification;

[0013] Fig. 6 is an example GUI of an Organization-level Configuration to enable a feature (e.g., an update feature) for a networked system for respiratory care as described in this specification;

[0014] Fig. 7 is an example GUI of an to edit therapy settings in a networked system for respiratory care as described in this specification;

[0015] Fig. 8 is a flow diagram illustrating an example data management process in a networked system for respiratory care as described in this specification;

[0016] Fig. 9 is an example GUI of an is an example GUI of a Durable Medical Equipment Provider Portal in a networked system for respiratory care as described in this specification;

[0017] Fig. 10A is an example GUI of a Patient App; Fig. 10B is an example GUI of a Caregive App; and Fig. 10C is an example GUI for viewing (e.g., symptom) history in a networked system for respiratory care as described in this specification; and

[0018] Figs. 11-84 are screenshots illustrating example interfaces (GUIs) and / or components thereof that can be used with a system for respiratory care as described in this specification.DESCRIPTION

[0019] Described in this specification are systems and methods for medical devices for respiratory therapy. The technologies described can be used in a hospital or home care setting and provide a user with means for monitoring and / or adjusting respiratory therapies.Hospital

[0020] Respiratory therapists (RTs) and other health care providers in the hospital setting must manage, treat and / or care for respiratory distress patients effectively, efficiently, and in a timely manner. They use varying protocols, digital tools, medical devices, and also maintain charting and documentation in the Electronic Health Records (EHR) system. Even though EHRs are the collectors of patient demographics, medications, medical history, provider notes, lab results, reports, and more, they are not designed to diagnose, mitigate nor prevent a disease. Therefore, RTs and other health care providers need to sort through various workflows and applications to find answers, fill gaps, and deliver care. In addition, some RTs do not have access to central patient monitoring tools and rely on nurse calls to respond to urgent patient needs. This leads to a highly reactive work environment and potentially delayed response times based on circumstances outside the RT’s control. Beyond the tools available to support patient care, there is also shortage of RTs needed to support the patients with Acute and Chronic respiratory issues, so additional mechanisms to help identify at-risk patients and allowing RTs to focus their efforts on the patients with the greatest need are needed. In addition, patient satisfaction is an increasingly important element of hospital care, and providing patients with care when needed, and letting patients rest comfortably to recover when care is not needed would serve to improve the patient experience.

[0021] It is fundamentally believed that care should be focused on prevention. However, currently EHRs system primarily support reactive care (after the fact documenting). With the segmentation of actionable information, RTs responding to respiratory distress patients / symptoms currently do not have the necessary means to be proactive, predictive, and preventative. While the industry tries to maintain safe and effective protocols to prevent delayed responses, there is substantial room for improvement and a gap to fill on predictive and preventative workflow modeling to obtain reduced response times that are most beneficial for patients, staff, and outcomes.Home

[0022] In respiratory care, patients are increasingly being treated in the home. Existing home therapies include low flow nasal cannula oxygen support, Bi-level and Continuous Positive Airway Pressure (BiPAP and CPAP) therapy, High Flow Therapy (HFT), and / or home mechanical ventilation. Home-care creates challenges around monitoring patients and adjusting their therapies. These challenges include the following.

[0023] Lack of monitoring: In a home environment, patients are not monitored as closely as when they are in the hospital. In the home environment, the patient may become disconnected from therapy, misuse therapy, or experience another emergent situation that is not discovered in time. These situations can lead to patient harm or otherwise reduce the effectiveness of the therapy. In addition, monitoring in the home environment is often of a lower quality and therefore results in a discontinuity of patient assessment based on the varying accuracy of the parameters being monitored.

[0024] Compliance: Patients do not always comply with their prescribed therapy. They may turn on a certain device, but not put on the patient interface. Therefore, they are not actually receiving the therapy. Caregivers, operating on the assumption that their patients are using the therapy, may make incorrect decisions based upon erroneous information. This may include increasing medication due to an assumption that the patient is not responding to therapy.

[0025] Prediction: When in the hospital, patients are heavily monitored by humans who can observe their signs and symptoms. The caregivers can pick up on subtle changes that predict a worsening of the patient’s condition. When in a home-care environment, the caregivers are not present or may not be as medically trained. These predictive indications may be missed. Additionally, in a home environment, intervention is considerably more time consuming than in a hospital. If a patient worsens quickly, additional aid may take a long time to arrive. Predicting when a patient will need additional support early would allow intervention to be ready when the patient needs it.

[0026] Education: In the home environment, patients need to be educated on the use of any devices they are prescribed and how the devices can help them. Currently, this is being done by DMEs in an ad hoc manner with no supporting tools. This causes information to be missed or confusion for the patient.

[0027] The technologies described in this specification include a set of technologies including digital tools that supply health care providers with meaningful, actionable, and predictive data including triaging of patients and risk stratification of symptoms all to improve outcomes, lower costs, and scale care effectively. These technologies include the followingFleet Management Portal for Hospital

[0028] The technologies include a web application designed for biomedical engineers and other non-clinical users to assist in the management of their connected devices within thehealth system’s network. The technologies allow for asset / fleet tracking and management. For example, the technologies provide remote over-the-air firmware and software updates, clock synchronization, display of active device alarms, display of actively in-use devices, virtual management of inventory, assistance in device swapping, track & remind maintenance schedules, track & remind device lifecycle and service cycles, device utilization trends, consumable utilization trends and recommended inventory orders, remote diagnostics, troubleshooting support, device location tracking, device logs, and / or education materials for the device.

[0029] In addition to providing timely and valuable information on the operation of the device(s), a predictive analytics application can leverage various datapoints like the current draw of the blower of a respiratory device and discrepancies in the mass flow sensors as well as the various error codes produced when a fault is observed to predict device and / or component failures before the device shuts down. When this occurs, replacement parts can be shipped to the customer, or notifications can be sent indicating future failure and enabling steps to be taken to minimize downtime.Clinician Portal and Mobile App for Hospital

[0030] The technologies include a web application for respiratory therapists and / or other clinical users to manage patients that are receiving care on connected devices, e.g., respiratory support devices. The backend can be integrated with the health system’s EHR and admission, discharge, and transfer (ADT) systems and allows for device and patient attribution. Consequently, the system provides bi-directional automation to and from the EHR, which assists in efficiency and accuracy. For example, the technologies include automated / virtual device assignments for patients (EMR), documentation of patient therapy data and device settings (On / Off, FiO2, Flow Rate, Temperature, Time) and other captured parameters, documentation of patient therapy data and device changes (On / Off, FiO2, Flow Rate, Temperature, Time) and other captured parameters, documentation of patient health data captured by a connected respiratory device (e.g., SpO2, Heart Rate), documentations of patient health data calculated by the system (e.g., Respiratory Rate, Breath Wave Analysis, Risk Score), collection of pertinent data from the EHR for efficient patient management in the clinician portal, clinical notifications (e.g., EMR popups, clinical texting, clinical emails, and other types of clinical alerts), or productivity points.

[0031] The technologies also allow for efficient triaging of patients and recommending one or more connected devices by taking into consideration various parameters including, but notlimited to, the device alarms, patient vitals, and / or respiration rate or work of breathing. The technologies can help determining trends and predicting changes in a patient’s respiratory condition (e.g., de-saturation, instability, or symptoms / disease progression). An accompanying mobile app may provide simplified functions.

[0032] In triaging patient conditions, the system can leverage an analytical system to review patterns in the data that can identify patient acuity. The analytical system may include a rule engine approach or may include a machine leaming / artificial intelligence approach. The data on which the analysis is be based may include pulse oximetry (real-time numerical data and / or trending), therapeutic parameters and / or changes in therapy, and respiratory rate (numerical data and / or trending). In addition, the data may also include tidal volume, respiratory resistance, respiratory impedance, and the Rox index. Leveraging this data, the analytic solution can identify patients with the highest risk of exacerbation or complication, or can force rank patients on the basis of acuity. This technique can then enable clinicians to focus on the highest acuity patients while letting the analytical system monitor lower acuity patients for any changes in risk or acuity.

[0033] In some implementations, a machine learning / artificial intelligence-based system can leverage the same data set to identify data patterns that can be predictive of patient risk or pending changes in patient risk. By identifying patients that are at risk of respiratory exacerbations or complications early, well before any changes in symptoms, such a system can enable interventions that can address the future risk at lower cost and with greater potential for a positive outcome.Reporting Portal for Hospital

[0034] A web application designed for non-clinical users requiring de-identified reporting to measure, analyze, evaluate, inspect, interpret and / or study captured metrics and parameters. The system allows for customizable and sophisticated exporting capabilities and tools for estimations, predictions, comparisons, and forecasting outcomes.Fleet Management Portal and App for Home

[0035] The technologies include a web application designed for a durable medical equipment provider (DME) and / or other equipment supplier stakeholders to efficiently manage their fleet of connected devices that are deployed in patients’ homes or other specialty care facilities. The technologies allow for asset / fleet tracking and management that can improve outcomes and save costs. The technologies provide for, e.g., remote prescription changes (device therapy setting ranges), patient compliance reporting, remote over-the-air firmwareand software updates, clock synchronization, display of active device alarms, track & remind & recommended maintenance schedules, track & remind device lifecycle and service cycles, device utilization trends, consumable utilization trends and recommended inventory orders, remote diagnostics and troubleshooting, virtual management of inventory, assistance in device swapping, report prescription updates, remote device changes / configurations, education on device setup / configuration / security, and / or an accompanying mobile app may provide simplified functions.

[0036] In addition to providing timely and valuable information on the operation of a device, e.g., a respiratory assist device, a predictive analytics application can leverage various datapoints like the current draw of the blower and discrepancies in the mass flow sensors as well as the various error codes produced when a fault is observed to predict device and / or component failures before the device shuts down. When this occurs, replacement parts can be shipped to the customer / DME or notifications can be sent indicating future failure and enabling steps to be taken to minimize downtime.Clinician Portal and Mobile App for Home

[0037] The technologies include a web application designed for primary care providers, pulmonologists, nurses, respiratory therapists, and / or other clinical users to manage patients that are receiving care on connected devices in a home setting. The backend can be integrated with the clinic or practice’s EHR system and allows for device attribution. Consequently, the system provides bi-directional automation to and from the EHR, which improves efficiency and accuracy. For example, the technologies include automated / virtual tools for: device assignments for patients (EMR), documentation of patient therapy data and device settings (On / Off, FiO2, Flow Rate, Temperature, Time) and other captured parameters, documentation of patient therapy data and device changes (On / Off, FiO2, Flow Rate, Temperature, Time) and other captured parameters, documentation of patient health data captured by a connected device (e.g. SpO2, Heart Rate), documentations of patient health data calculated by the system (e.g., Respiratory Rate, Breath Wave Analysis, Risk Score), collection of pertinent data from the EHR for efficient patient management in the system’s clinician portal, clinical notifications (e.g., EMR pop-ups, clinical texting, clinical emails, and other types of clinical alerts), and / or remote prescription updates.

[0038] The technologies allow for efficient triaging of patients and recommending one of our connected devices by taking into consideration various parameters including, but not limited to, device alarms, patient vitals, and / or respiration rate or work of breathing. The applicationcan determine trends and predict changes in a patient’s respiratory condition (e.g., desaturation, instability or symptoms / disease progression). An accompanying mobile app may provide simplified functions.

[0039] In triaging patient condition, the system can leverage an analytical system to review patterns in the data that would identify patient acuity. The analytical system may include a rule engine approach or may include a machine learning / artificial intelligence approach. The data on which the analysis is be based can include pulse oximetry (real-time numerical data and / or trending), therapeutic parameters and / or changes in therapy, and / or respiratory rate (numerical data and trending). In addition, the data may also include tidal volume, respiratory resistance, respiratory impedance, and / or the Rox index. Leveraging this data, the analytic solution can identify patients with the highest risk of exacerbation or complication, or can force rank patients on the basis of acuity. This technology can enable clinicians to focus on the highest acuity patients while letting the analytical system to monitor lower acuity patients for any changes in risk or acuity.

[0040] A machine learning / artificial intelligence-based system can leverage the same data set to identify data patterns that would be predictive of patient risk or pending changes in patient risk. By identifying patients that are at risk of respiratory exacerbations or complications early, well before any changes in symptoms, interventions can be performed that could address the future risk at lower cost and with greater potential for a positive outcome.Patient App for Home

[0041] The technologies include a mobile application designed for caregivers and / or patients assigned a connected home device, e.g., a connected respiratory care device. Caregivers and / or patients are provided with transparency, ownership, visibility, and equipped with their device data along with other useful lifestyle tools pertinent to their diagnosis and device details. This information improves a patient’s knowledge of their condition, treatments, therapies, and / or symptoms, consequently improving their reported outcomes and disease management skills. The technologies allow patients to visualize their device usage and settings, input of symptoms, accept prescription changes (device therapy setting ranges) virtually, approve over-the-air firmware and software updates, schedule device appointments, share information with others, be alerted on disposables, refills, device alarms, and / or other time sensitive information. Further wellness promoting features can aid in patient education about disease management, proper device and disposables usage, condition understanding, troubleshooting support, community forums, coaching, scheduling, and / or outreach supportalong with other tools. Caregivers can have access to disease management coaching tips as well as patient information, reports, and relevant notifications. Both patients and caregivers can be provided with help, e.g., provided to ensure appropriate canula placement and / or other tips to use the device.

[0042] In some implementations, a system architecture includes the components discussed below, as shown in Fig. 1. An example system includes one or more Cloud Databases. Multiple relational databases are used in the system architecture to support the data storage requirements. These databases are hosted in a managed service, e.g., in a Google Cloud Platform called Cloud SQL. The databases are partitioned efficiently to store organization, users, clinical and fleet data. An example system includes one or more Clinical Management Microservices: The Clinical Management Microservices are responsible for managing clinical data for all patients coming from the device and EMR. An example system includes one or more Fleet Management Microservices: The Fleet Management Microservices are responsible for managing device fleet data regarding device utilization, disposable utilization, and maintenance. This service also manages over the air (OTA) software update for the devices. An example system includes one or more Portal Management Microservices: The Portal Management Microservices are responsible for managing organization, user, user authorization, user authentication, and / or device registrations, and can process one or more compliance reports. An example system includes an API Management device: This component is responsible for managing external representational state transfer (REST) requests and route these requests to the appropriate microservices. An example system includes a Data Ingestion Service: The Data Ingestion Service is responsible for storing the data in raq format and ingesting device data and extract the device data into appropriate data storage. An example system optionally includes an AI / Data Analytics Service: The AI / Data Analytics Service is responsible to intelligently render meaningful insights for use by the clinicians. An example system includes a Portal UI : The Portal UX is a Web application for users and clinician to view and manage information. An example system includes one or more Therapy Devices: The therapy devices provide respiratory support to the patient. The devices may include High Velocity Nasal Cannula therapy, CPAP, BiPAP, mechanical ventilation, High Flow nasal cannula therapy, low flow oxygen therapy, or any other form of respiratory support. The therapy devices serve as a central point for clinical data collection and transmission of data to the cloud. An example system includes one or more Third-party Systems: Third-party Systems are system that can be integrated into the device cloud throughRESTful API to collaborate data collection from external sources. An example system includes device of one or more Mobile Users: These are the users who wish to use mobile device to view data in the Cloud. An example system includes devices of one or more Clinicians: These are the clinical user who view clinical information about the patients that they care for.

[0043] The technologies described in this specification improve the standard of care. The technologies allow for triaging of patients that are associated with respiratory care devices in in-patient and out-patient settings. For example, the technologies may detect an X percentage (%) drop in oxygen saturation over Y amount of time. For some patients, a drop of 1% to 10% may be relevant over a period of a minutes, hours, days, weeks. These changes can be compared to the patient’s baseline measurements. The data used for triaging patient conditions may include pulse oximetry (both numerical values and trending), therapeutic parameters and / or changes in therapy, respiratory rate (numerical data and trending), and additional measured parameters to include respiratory resistance, respiratory impedance, tidal volume, and / or Rox index.

[0044] For example, the technologies can use changes in respiratory rate or more appropriately a sustained trend indicating an increasing respiratory rate that may be indicative of increased work of breathing indicating an increasing risk or acuity of the patient.

[0045] The technologies described in this specification provide an infrastructure to gather longitudinal data to predict disease progression, outcomes, and patient management, for example, using analytics to predict trends and future outcomes. The technologies can collect and / or process information including Patient demographics and location, Increasing trends in flow rate used, Improvement in baseline symptoms, Changes in work of breathing, Changes in sputum discharge, Changes in SpO2, Changes in pulse rate, Changes in device therapy settings, Changes in respiratory rate, and / or Therapy and activity compliance, Trends in these parameters can predict potential outcomes, such as Decrease in hospitalization, Decrease / Increase in quality of life, Changes in patient baseline, Medication / therapy changes, Probability of patient not meeting monthly compliance. The technologies include a novel system for capturing and presenting respiratory patient data, trends, insights, and notifications shared with caregivers and health care providers. The technologies also include a novel system for predicting symptom changes and potential exacerbations, for example, predicting a potential oncoming COPD symptom exacerbation that may lead to hospitalization. Exacerbations are predicted by changes in one or more of the following conditions:respiratory rate, oxygen saturation, exercise or mobility, coughing, dyspnea, sputum discharge, sputum color and consistency, temperature, sore throat, nasal congestion, wheeze, and / or therapy usage.

[0046] The technologies include a novel system to decrease the amount of data needed to calculate breath waveforms, e.g., wavelet scaling, compression, and / or Fourier transforms.

[0047] The technologies include a novel UI / UX design on a hospital therapy device to identify the patient receiving therapy by their medical record number (MRN). The device can implement workflows that encourage entry of the MRN number but without requiring it to deliver therapy, as this information may not be immediately available when the patient first presents. The MRN is required to associate the data transmitted from the device to the correct patient record.

[0048] The technologies include novel features that combine use of device data, patient vitals, respiratory data, and / or patient symptom submissions allowing for more effective and efficient triaging and management of lung disease patients. The technologies combine both objective and subjective data to score patient reported outcomes. This combination can lead to improved outcomes because of the ability to adjust therapy or interventions more quickly based on the patient’s needs. The technologies provide enhanced patient safety using the right alerts at the right time.

[0049] The technologies provide near real-time insights and alerts that give respiratory care providers a better view of patient status than currently exists in their workflows. The longitudinal data sets provided by the technologies described in this specification combine data on the patient from their care at home with their care in the hospital, which allows for more specific ML / Al analytics, predictions, and / or interventions for lung disease patients using the respiratory assist systems.

[0050] The technologies provide more efficient equipment supply and management through usage analytics to predict resupply and servicing or replacement needs. The described system provides reimbursable remote patient monitoring while the current technologies do not.

[0051] The described system can predict potential patient symptom exacerbations while the current technologies do not. Moreover, the technologies provide incorporated breathlessness and SpO2 measurements.

[0052] The technologies described in this specification help healthcare providers (particularly respiratory therapists) to streamline their workflows and improve theirproductivity and help caregivers get notifications on the status or help needed for those that are under their care.

[0053] In some implementations, the technologies described in this specification allow to predict patient symptom exacerbations using various types of questions and / or the way questions are asked. In addition to or alternatively to collecting information through questions and answers, other implements, e.g., Sputum collectors can be used in place of asking patients about their sputum quantity, thickness, and color.Distributed Alarm and Resolution System Associated with Home Medical Devices

[0054] Respiratory patients in a non-acute setting (e.g., at home) typically lack the real-time monitoring that exists in the hospital setting. With existing connected home medical devices, the intervals of data transmission from the device can sometimes be, e.g., 4 hours and even up to 24 hours, or more. For urgent device alarms, this delay in response can lead to considerable risk and patient harm.

[0055] Home medical devices have audible and / or visual alarm displays on the device itself, but patients and their caregivers must be near the device to see or hear the alarm. If a caregiver / lay operator were in, e.g., another room, tending to errands, or residing in a different location from the patient they may not know that the patient’s medical device has an alarm, which can lead to a delayed response and potential patient harm.

[0056] Described in this specification is an ecosystem of connected devices and digital tools that supply health care providers, lay operators / caregivers, and / or patients with soft-real-time notification of alarms and information on how to resolve them. The technologies include connected medical devices and a cloud management platform.Connected Medical Device

[0057] The technologies include one or more medical devices that can provide high velocity respiratory therapy and volume assured ventilation support for respiratory patients in a non- acute setting. An example device has an integrated cellular modem that transmits device alarm details in soft-real-time to a cloud management platform (in soft real time, a latency of, e.g., 1-3 seconds may be tolerated). In addition, the device can connect with a companion mobile app via Bluetooth to transmit the alarm details if the integrated cellular modem fails or is disabled.Cloud Management Platform

[0058] The technologies include a management platform hosted in the cloud that ingests data from patient endpoints (e.g., a medical device, peripheral devices, device GUI data inputs, and / or mobile app data inputs), transforms and processes the data, and triggers communications from the resulting outputs. When a connected medical device alarms, the Cloud Management Platform receives the alarm details, and then sends email notifications, SMS text notifications, push notifications, and / or in-app messaging to the patient, assigned caregivers / lay operators, and / or medical equipment provider personnel. These notifications notify the recipients that an alarm is occurring on the home medical device and may contain information on how to resolve it.Provider Web and Mobile Application

[0059] The technologies include a web and mobile application designed for providers (e.g., HME / DME, HCP, etc.) to efficiently manage their patients and fleet of connected devices that are deployed in patients’ homes or specialty care facilities. The application presents active alarms that are occurring and the relevant information to resolve them. The application also helps triage patients based on alarm priority level. The application can also allow for configurability of notification preferences based on alarm priority levels. When alarms are cleared on the device, they are also cleared in the application. Stakeholders using the provider application are also able to indicate (e.g., via the application / GUI) that they are assisting with an alarm(s), which will notify other stakeholders that had received distributed alarms of the fact that the alarm is being responded to (e.g., “Jane Smith is responding to the Water Level Low alarm.”).Patient and Caregiver Web and Mobile Application

[0060] The technologies include web and mobile application designed for caregivers, patients, and lay operators assigned a connected (respiratory care) home device. Caregivers and / or patients are provided with soft-real-time device alarm information on their homepage. The relevant alarm information can be easily accessed by, e.g., caregivers and / or patients to inform them on how to resolve the alarm. The application also helps triage multiple alarms based on priority level. The application also allows for configurability of notification preferences based on alarm priority levels. When alarms are cleared on the device, they are also cleared in the application. Stakeholders using the patient and caregiver application are also able to indicate (e.g., via an application / GUI) that they are assisting with an alarm(s), which will notify other stakeholders that had received distributed alarms of the fact that the alarm is been responded to (e.g. “Jane Smith is responding to the Water Level Low alarm.”).

[0061] The technologies described in this specification seamlessly integrate diverse data sources as in device alarms, therapy compliance metrics, symptom variations, and or comprehensive patient monitoring. Upon triggering, a device promptly initiates an alarm request transmitted to the API Management service for seamless integration (e.g., as illustrated in the diagram shown in Fig. 2).

[0062] After transmission, the data undergoes processing within the Data Ingestion System, ensuring validation and secure storage. Following this sub-process, the data is passed to the Organizational service, undergoing in-depth analysis to discern the nature of the alarm and how it will be resolved.

[0063] Upon completion of analysis, the processed data seamlessly transitions to the Notification Service. Here, it is systematically queued and pushed out to provider, patient, caregivers, and / or other stakeholders simultaneously through various communication channels, such as mobile applications, email, and / or SMS. In some implementations, all alarm requests are transmitted on a first-come, first-served basis. The alarms are prioritized according to pre-defined alarm priority settings for ease of triaging and displayed on the patient dashboard. When, e.g., a caregiver indicates that they are taking care of the alarm on the mobile app, this indication is received and processed by the Organizational service and notifications are sent to all other caregivers and providers, e.g., that the alarm is being addressed by the caregiver.

[0064] Data security is addressed by encrypting all communications, ensuring they are securely transmitted using, e.g., TLS 1.3 standards. Upon arrival at the API Management service, data undergoes decryption and validation to maintain its integrity. Within the secure Virtual Private Cloud (VPC), all data processing occurs, with encryption managed by, e.g., Google Cloud Platform's Key Management Service (KMS) for storage. The Notification Service efficiently handles incoming requests, utilizing, e.g., RabbitMQ for queuing and dispatching within minutes, enabling timely and secure communication with stakeholders. Additionally, all the services are managed by GKE, allowing them to dynamically scale based on traffic demands.

[0065] The technologies described in this specification include a method for securely transmitting alarm data from a medical device to a cloud platform management system and processing the outputs and relaying the alarm information to communications channels in soft-real-time. These communications are being sent to multiple stakeholders simultaneously, including the patient’s caregiver which isn’t common in the respiratory care industry.

[0066] In addition to a description of the alarm that is occurring, the system also provides users with the relevant information on how to resolve the alarm as well as appropriate contact information for support personnel if the alarm can’t be resolved by the user.

[0067] The technologies described in this specification provide the ability for stakeholders receiving the distributed alarm to respond whether or not they are able to assist with the alarm(s) and notify the other stakeholders of responses / non-responses.

[0068] The technologies described in this specification provide for prioritization and triage of multiple alarms. The system includes instructions on how to prioritize alarms and, e.g., assign a priority score to each alarm. In some implementations, the alarms are displayed on one or more GUIs, e.g., on a Patient App (Fig. 3A) or a Caregiver App (Fig. 3B). In some implementations, only the highest priority alarm is displayed (e.g., as shown in Fig. 3A). In some implementations, multiple alarms are displayed in order of priority (e.g., top-down and / or using color coding), e.g., as shown in FIG. 4A. In some implementations, alarm details can be displayed, e.g., as shown in FIG. 4B. In some implementations, alarms are displayed on a Provider Web App, e.g., in order of priority, e.g., as shown in Fig. 5. Alarms that have been addressed are either removed from display or color coded accordingly, e.g., greyed out.

[0069] The alarm information can be being relayed simultaneously to multiple stakeholders and / or multiple GUIs / applications within their existing communication mediums (e.g. emails, text messages, push notifications, apps). Separate devices like a pager, smart watch, etc. can receive alarm notifications simultaneously. The alarms can be integrated with other smart home devices / sy stems, e.g., with respiratory devices that are integrated with smart phones and other smart devices.

[0070] In addition to a description of the alarm that is occurring, the system also provides one or more users with the relevant information on how to resolve the alarm as well as appropriate contact information for support personnel if the alarm cannot be resolved by the user.Remote Therapy Settings Updates for Respiratory Medical Devices

[0071] Respiratory medical devices in non-acute settings (e.g., home) typically require a technician to be physically present with the patient’s medical device in order to update its therapy settings. For a home / durable medical equipment provider (HME / DME), this means that when a provider desires to change a patient’s therapy settings, they need to dispatch a technician to go to the patient’s home to make the therapy settings update. This processrequires a significant amount of human resources to handle each therapy setting update. For example, it can take a few hours to a full day for a technician to complete this task depending on the patient’s geographical location.

[0072] Currently, there is a need for life-supporting medical devices used in non-acute or home settings to have the capability of updating device therapy settings without making the update on the device itself (i.e. a need for remote update capability). Fig. 6 shows a GUI with an example organization-level configuration to enable the update feature.

[0073] The technologies described in this specification include a cloud management platform and web and mobile application that allows providers to remotely update the therapy settings of respiratory medical devices in a non-acute setting. After logging into the application, a provider can select a patient and edit their device’s therapy settings, e.g., Fig. 7. The settings of a respiratory device that can be updated using the technologies described in this specification include gas temperature, gas humidity, FiO2, and / or flow rate. Settings can include low, medium, and high settings and can include alarm limits. The interface can include a functionality by which a user can attest to having the authority to effect changes in the settings. Once updated, the patient’s device will automatically retrieve the therapy setting update from the cloud management platform and present a confirmation on the device’s touchscreen. When the patient confirms the update on the device touchscreen, the device will then automatically complete the therapy setting update when the device is not actively running therapy. The updated settings are reflected in the therapy logs, which can be transmitted to the cloud management platform and reflected on the web and mobile application. This technology provides closed-loop visibility of the entire remote therapy setting update process.

[0074] This remote therapy setting update process allows providers to save substantial human resources time by not needing to dispatch a technician to the patient’s home to make the settings update on the device.

[0075] An example system includes a series of mitigations and cybersecurity implements. The mitigations and cybersecurity feature may be enabled at the system level. The device can limit the feature to be enabled only in specific geographies where it is available. In some implementations, access to the feature is role based. Therapy setting update requires attestation of authority to make the update, and a patient must confirm the update on the device screen. Optionally, a Patient must enter a PIN or must enter their date of birth. In some implementations, the update only takes place when therapy is not actively running.

[0076] The technologies provide the ability to add an additional PIN number a patient must enter on the device screen to accept the remote therapy setting update. This feature can facilitate a workflow where the provider making the remote therapy settings update is on the phone with the patient and tells the patient to enter the PIN to accept. The technologies provide the ability to add date of birth entry on the device screen by the patient to verify identity in order to accept the remote therapy setting update.

[0077] Remotely adjusting a patient’s therapy settings can present a risk. The clinician is not present to observe the effects of therapy changes on the patient. The remote monitoring technology allows the clinician or caregiver to observe the effects of any therapy setting change. Settings can be rolled back by, e.g., the clinician or the patient if the updated therapy is not achieving the desired outcome. In some implementations, if the patient decides to revert to previous settings, the clinician or caregiver is notified by the system.Remote Patient Management Associated with Home Medical Devices

[0078] The technologies described in this specification include a set of digital tools that supply providers with meaningful, actionable, and predictive data including triaging of patients and risk stratification of symptoms to improve outcomes, lower costs, and / or scale care effectively. The technology includes connected home medical devices, a cloud management platform, provider web and mobile applications, patient / caregiver web and mobile applications.Connected Home Medical Device

[0079] The technologies include one or more medical devices in a non-acute setting that can provide high velocity therapy and volume assured ventilation support for respiratory patients. The devices are equipped with a touch screen (or other means) where patients can enter their daily symptoms. The example device has an integrated cellular modem that transmits the device therapy usage and setting, alarms, symptom details, and other information in soft-real- time to a cloud management platform. In addition, the device has the capability to connect with a companion mobile app via Bluetooth to transmit the data if the integrated cellular modem fails or is disabled.Cloud Management Platform

[0080] The technologies include a management platform hosted in the cloud that ingests data from patient endpoints (e.g., medical device, peripheral devices, device GUI data inputs, and / or mobile app data inputs), transforms and processes the data, and triggers communications from the resulting outputs. This technology allows for the appropriateinformation to be displayed on the provider’s patient management portal, the patient / caregiver app, and reports.Provider Web and Mobile Application

[0081] The technologies include an application designed for providers and / or their stakeholders to efficiently manage their fleet of connected devices that are deployed in patients’ homes or specialty care facilities. The technology allows for triaging a panel of patients based on their symptom changes, therapy compliance status, pulse oximetry readings, active device alarms, disposables lifecycle, and / or other information.Patient and Caregiver / Lay Operator Web and Mobile Application

[0082] The technologies include mobile application designed for caregivers, lay operators, and / or patients assigned a connected (respiratory care) device. The patient app allows entry of their daily symptoms from their home screen. Both the patient and caregiver app display any active device alarms and information on how to resolve them, views of their therapy usage history, disposables lifecycle, pulse oximetry history, symptom history, and / or other information. The caregiver app can also display their associated patient’s symptom changes and any recommended actions to take.Patient SMS Text Symptom Entry

[0083] In addition to being able to enter their daily symptoms on the device screen or mobile application, patients are provided with the capability to enter their symptoms through a SMS text-based interaction. If a patient has not entered their symptoms by a configurable time (e.g., by 10AM), they will receive a text (automatically generated by the system) to remind them to enter their symptoms, or enter their symptoms via text. In some implementations, the system is configured to text each question one at a time and ask the patient to respond.

[0084] A connected respiratory care device as described in this specification sends out various patient and device data, such as device alarms, therapy compliance, pulse oximetry, disposable usage and / or more, in various intervals (Figs. 2 and 8). In some implementations, an API Management service receives this data and passes it to the Data Ingestion service for validation and storage. A Reporting service rolls up the data into the required intervals and runs a compliance algorithm and various reports to inform patients and caregivers (e.g., on a Patient / Caregiver Device).

[0085] At certain intervals, e.g., once a day, or twice or more per day, the patient does a check-in on the device (e.g., on the Patient / Caregiver Device) that the Access Service runs through the Access Algorithm and can notify stakeholders of predicting symptom changes,potential risks, and personalized recommendations. This data is being sent over to the Notification service, where it is systematically queued and sent out to both patients and caregivers through various channels like mobile apps, email, and SMS, ensuring timely and effective communication. This information helps health care providers keep patients from hospital readmissions by providing relevant information in a timely manner.

[0086] Patient triaging can be carried out through an Organization Service engine. This patient prioritization will be configurable through the provider web application. The Organization Service includes the following settings and prioritizations, e.g., as illustrated in Fig. 9, showing an example Durable Medical Equipment Provider Portal). The settings / prioritizations include “Account Status,” which is or includes the patient’s account status. The status / prioritization of Account Status can be “Connection issue”, “Active”, “Temporarily locked” (from too many failed login attempts), “Completely locked” (after too many temporary locks), or “Terminated.” The settings / prioritizations include “Active Alarms,” which can be or include “Warning”, ““Caution” (Medium priority or Low priority), or “Notice / Advisory .” The settings / prioritizations include “Symptom Change,” which can be or include “Major”, “Moderate”, “Mild”, “Baseline”, or “Not recorded.” The settings / prioritizations include “Initial 90-Day Compliance - At Risk” (patient has Compliance Type “Initial 90-day” and missed between 3 to 9 days). In some implementations, the symptom changes are tracked / displayed on one or more GUIs, e.g., on a Patient App (Fig. 10A) or a Caregiver App (Fig. 10B). An example display of symptom change history is shown in FIG. 10C. The system has the capability to update the Compliance “At Risk” definition to include additional parameters, such as alarm counts, recurring alarms, therapy usage patterns, and other information. The settings / prioritizations include “Initial 90-Day Compliance - Not Compliant” (patient has Compliance Type “Initial 90-day” and missed 10 or more days). The settings / prioritizations include “Ongoing Compliance - At Risk” (patient has Compliance Type “Ongoing” and missed between 3 to 9 days). The system has the capability to update the Compliance “At Risk” definition to include additional parameters, such as alarm counts, recurring alarms, therapy usage patterns, and other information. The settings / prioritizations include “Ongoing Compliance - Not Compliant” (patient has Compliance Type “Ongoing” and missed 10 or more days). The settings / prioritizations include “Disposables Lifecycle Status,” which can be or include “Past due” (highest days to lowest), or “Days left” (lowest days to highest). The settings / prioritizations include “Initial 90-Day Compliance - Compliant.” The settings / prioritizations include “Ongoing Compliance - Compliant.”

[0087] In some implementations, patient list prioritization does not consider terminated accounts, and uses SpO2 and Pulse Rate as tie-breakers (lower SpO2 is higher priority, and higher Pulse Rate is higher priority). The system has the capability to update the prioritization methodology, such as factoring in the onset of new persistent symptoms, persistent or long duration alarms, etc. Security is provided by encrypting all communications to securely transmit information using TLS 1.3 standards. Upon arrival at the API Management service, data undergoes decryption and validation to maintain its integrity. All data processing occurs in a secure Virtual Private Cloud (VPC), with encryption managed by, e.g., Google Cloud Platform's Key Management Service (KMS) for storage. The Notification Service efficiently handles incoming requests, utilizing, e.g., RabbitMQ for queuing and dispatching within minutes, providing timely and secure communication with stakeholders. Additionally, all services are managed by GKE, allowing them to dynamically scale based on traffic demands.

[0088] The technologies described in this specification provide patient triaging based on active device alarms, therapy compliance, symptom changes, pulse oximetry readings, disposables lifecycle, and / or other information.

[0089] The technologies described in this specification provide an infrastructure for monitoring and trending patients’ compliance progress and at-risk compliance. A current definition of compliance at-risk is if the patient does not achieve between 3 to 9 days of at least 4-hour therapy usage per day. The technologies provide the capability to update the Compliance “At Risk” definition to include additional parameters, such as alarm counts, recurring alarms, therapy usage patterns, and other information.

[0090] Current systems for assessing patient symptom exacerbation risk as a function of symptom changes from baseline lack the capability to collect symptom entries in different ways and delivering personalized recommended actions to take for the patient and caregiver / lay operator in different ways. Current systems only capture symptoms and delivered recommendations on a mobile app, web app, and phone call, whereas systems as described in this specification capture symptom entries from a device screen and deliver recommendations to the device screen, caregiver / lay operator application, email, and / or SMS text.

[0091] The technologies described in this specification improve the standard of care by combining device data, patient physiological measures, respiratory data, and / or patient symptom submissions, allowing for more effective and efficient triaging and management of patients. This technology provides improved outcomes because of the ability to adjusttherapy or interventions more quickly based on the patient’s needs. The technology provides personalized recommended actions that help patients predict worsening of their own symptoms and proactively manage their symptoms. The technology provides Soft-real-time insights and alerts that give respiratory care providers a better view of patient status than provided by current technology.

[0092] The technology provides more efficient equipment supply and management through usage analytics to predict resupply and servicing or replacement needs.

[0093] In some implementations, the technologies provide can help predict patient symptom exacerbations through a set of questions presented to patients. The system can provide different ways of calculating a baseline set of symptoms (e.g., mode average vs 30-day average, etc.), can provide different methodologies of asking (e.g., on device or app, SMS message, email), different scoring methodologies (e.g., different weightings), and / or different questions. In some implementations, sputum collectors can be used in place of asking patients about their sputum quantity, thickness, and color. Moreover, other respiratory measurement devices can be used in place of a peak flow meter to obtain input flow data.

[0094] The foregoing is merely illustrative of the principles of the disclosure, and the systems, devices, and methods can be practiced by other than the described implementations, which are presented for purposes of illustration and not of limitation. It is to be understood that the systems, devices, and methods disclosed herein, while described for use in respiratory (e.g., high flow) therapy systems, may be applied to systems, devices, and methods to be used in other ventilation circuits.

[0095] Variations and modifications will occur to those of skill in the art after reviewing this disclosure. The disclosed features may be implemented, in any combination and subcombination (including multiple dependent combinations and sub-combinations), with one or more other features described herein. The various features described or illustrated above, including any components thereof, may be combined or integrated in other systems.Moreover, certain features may be omitted or not implemented.

[0096] Examples of additions, changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the scope of the information disclosed herein. Examples of such additions, changes, substitutions, and alterations, e.g., of a UI / UX design that provides for entry of the Patient ID when the patient first presents as well as designs accounting for different hospital workflows, including those allowing therapy to begin before the Patient ID is known, are shown in Figs. 11-84.Example Implementations

[0097] Al. A method for controlling a medical device, comprising: receiving, by a processor of a medical device, from one or more processors of one or more respiratory care devices, a plurality of data sets, each data set corresponding to a current alarm; querying, by the processor, a database comprising one or more a priority values, each priority value corresponding to at least one alarm; assigning, by the processor, a priority value to each received alarm; and displaying, on a graphical user interface (GUI), the alarms in order of priority.

[0098] A2. The method of item Al, comprising displaying only the alarm with the highest priority value.

[0099] A3. The method as in any one of items Al -2, comprising displaying two or more current alarms wherein each alarm comprises a graphical element with a different color.

[0100] A4. The method as in any one of items Al-3, comprising displaying the current alarms on a sorted list in descending order.

[0101] A5. The method as in any one of items Al-4, comprising displaying a record of past alarms.

[0102] A6. The method of item A5, comprising displaying two or more past alarms wherein each alarm comprises a graphical element with a different color.

[0103] A7. The method as in any one of item A5-6, comprising displaying the past alarms on a sorted list in descending order.

[0104] A8. The method as in any one of item Al-7, comprising displaying information on how to resolve each alarm.

[0105] A9. The method as in any one of items Al-8, comprising receiving, from one or more processors of one or more respiratory care devices that data indicating that an alarm has been resolved and removing resolved alarms from the GUI.

[0106] Bl. A method for controlling a medical device, comprising: receiving, by a processor of a medical device, one or more data sets, each data set comprising setting values for operating a respiratory care device; transmitting, by the processor of the medical device, to one or more processors of one or more respiratory care devices, the one or more data sets; updating, by the one or more processors of one or more respiratory care devices, the settings of the one or more respiratory care devices, and delivering, by the one or more respiratorycare devices, a breathing gas to a patient under updated operating conditions based on the received setting values.

[0107] B2. The method of item Bl, wherein the medical device is a remote device electronically connected to the respiratory care device via an internet data connection.

[0108] B3. The method of as in any one of items Bl -2, wherein the settings include one or more of gas temperature, gas humidity, FiO2, and / or flow rate.

[0109] B4. The method of as in any one of items Bl-3, wherein the settings include one or more alarm limits.

[0110] B5. The method of as in any one of items Bl -4, comprising receiving, by the processor of the medical device, data comprising a user identification and updating the settings only if the user identification matches a stored value.[OHl] B6. The method of as in any one of items Bl -5, wherein the patient’s vital signs are remotely monitored following a setting update.

[0112] B7. The method of item B6, wherein the settings are reverted to previous values if the desired effect of the settings change is not achieved.

[0113] Cl. A method for controlling a medical device, comprising: receiving, by a processor of a medical device, from one or more processors of one or more respiratory care devices, data comprising respiratory care device operation information and, from one or more processors of patient device, patient data comprising symptom information, and displaying, on a graphical user interface (GUI), the operation information and symptom information.

[0114] C2. The method of item Cl, wherein the symptom information is received daily.

[0115] C3. The method as in any one of items Cl -2, wherein the symptom information is received from one or more mobile devices via SMS.

[0116] C4. The method as in any one of items Cl-3, wherein communication between the devices is encrypted.

[0117] C5. The method as in any one of items Cl -4, comprising causing, by the processor of the medical device, transmittal of a text message to one or more to remind a user to transmit symptom information.

[0118] C6. The method as in any one of items Cl -5, comprising displaying, on the GUI, patient symptom changes and recommended actions to take.

[0119] C7. The method as in any one of items Cl-6, comprising querying, by the processor, a database comprising one or more a priority values, each priority value corresponding to a set of values comprising therapy compliance status, pulse oximetry readings, active devicealarms, disposables lifecycle, and / or other information; assigning, by the processor, a priority value to a set of symptoms; and displaying, on a graphical user interface (GUI), the symptoms in order of priority.

[0120] C8. The method of items C7, comprising triaging a panel of patients based on the priority value.

[0121] SAI. A system for respiratory care, comprising: at least one processor electronically coupled to a medical device for respiratory care; and a memory electronically coupled to the at least one processor, the memory containing a set of instructions, wherein the instructions, when executed by the processor, cause the processor to: receive, by a processor of the medical device, from one or more processors of one or more respiratory care devices, a plurality of data sets, each data set corresponding to a current alarm; query, by the processor, a database comprising one or more a priority values, each priority value corresponding to at least one alarm; assign, by the processor, a priority value to each received alarm; and display, on a graphical user interface (GUI), the alarms in order of priority.

[0122] SA2. The system of item SAI, wherein the set of instructions, when executed by the processor, cause the processor to: display only the alarm with the highest priority value.

[0123] SA3. The system as in any one of items SAI -2, wherein the set of instructions, when executed by the processor, cause the processor to: display two or more current alarms wherein each alarm comprises a graphical element with a different color.

[0124] SA4. The system as in any one of items SAI-3, wherein the set of instructions, when executed by the processor, cause the processor to: display the current alarms on a sorted list in descending order.

[0125] SA5. The system as in any one of items SAI -4, wherein the set of instructions, when executed by the processor, cause the processor to: display a record of past alarms.

[0126] SA6. The system of item SA5, wherein the set of instructions, when executed by the processor, cause the processor to: display two or more past alarms wherein each alarm comprises a graphical element with a different color.

[0127] SA7. The system as in any one of items SA5-6, wherein the set of instructions, when executed by the processor, cause the processor to: display the past alarms on a sorted list in descending order.

[0128] SA8. The system as in any one of items SAI-7, wherein the set of instructions, when executed by the processor, cause the processor to: display information on how to resolve each alarm.

[0129] SA9. The system as in any one of items SAI -8, wherein the set of instructions, when executed by the processor, cause the processor to: receive, from one or more processors of one or more respiratory care devices that data indicating that an alarm has been resolved and remove resolved alarms from the GUI.

[0130] SB1. A system for respiratory care, comprising: at least one processor electronically coupled to a medical device for respiratory care, a memory electronically coupled to the at least one processor, the memory containing a set of instructions, wherein the instructions, when executed by the processor, cause the processor to: receive, by a processor of a medical device, one or more data sets, each data set comprising setting values for operating a respiratory care device; transmit, by the processor of the medical device, to one or more processors of one or more respiratory care devices, the one or more data sets, update, by the one or more processors of one or more respiratory care devices, the settings of the one or more respiratory care devices, and deliver, by the one or more respiratory care devices, a breathing gas to a patient under updated operating conditions based on the received setting values.

[0131] SB2. The system of item SB1, wherein the medical device is a remote device electronically connected to the respiratory care device via an internet data connection.

[0132] SB3. The system of as in any one of items SB 1-2, wherein the settings include one or more of gas temperature, gas humidity, FiO2, and / or flow rate.

[0133] SB4. The system of as in any one of items SB1-3, wherein the settings include one or more alarm limits.

[0134] SB5. The system of as in any one of items SB 1-4, wherein the set of instructions, when executed by the processor, cause the processor to: receive, by the processor of the medical device, data comprising a user identification and update the settings only if the user identification matches a stored value.

[0135] SB6. The system of as in any one of items SB 1-5, wherein the patient’s vital signs are remotely monitored following a setting update.

[0136] SB7. The system of item SB6, wherein the settings are reverted to previous values if the desired effect of the settings change is not achieved.

[0137] SCI. A system for respiratory care, comprising: at least one processor electronically coupled to a medical device for respiratory care, a memory electronically coupled to the at least one processor, the memory containing a set of instructions, wherein the instructions, when executed by the processor, cause the processor to: receive, by a processor of a medicaldevice, from one or more processors of one or more respiratory care devices, data comprising respiratory care device operation information and, from one or more processors of patient device, patient data comprising symptom information, and display, on a graphical user interface (GUI), the operation information and symptom information.

[0138] SC2. The system of items SCI, wherein the symptom information is received daily.

[0139] SC3. The system as in any one of items SC 1-2, wherein the symptom information is received from one or more mobile devices via SMS.

[0140] SC4. The system as in any one of items SC1-3, wherein communication between the devices is encrypted.

[0141] SC5. The system as in any one of items SC 1-4, wherein the set of instructions, when executed by the processor, cause the processor to: cause, by the processor of the medical device, transmittal of a text message to one or more to remind a user to transmit symptom information.

[0142] SC6. The system as in any one of items SC 1-5, wherein the set of instructions, when executed by the processor, cause the processor to: display, on the GUI, patient symptom changes and recommended actions to take.

[0143] SC7. The system as in any one of items SC1-6, wherein the set of instructions, when executed by the processor, cause the processor to: query, by the processor, a database comprising one or more a priority values, each priority value corresponding to a set of values comprising therapy compliance status, pulse oximetry readings, active device alarms, disposables lifecycle, and / or other information; assign, by the processor, a priority value to a set of symptoms; and isplay, on a graphical user interface (GUI), the symptoms in order of priority.

[0144] SC8. The system of item SC7, wherein the set of instructions, when executed by the processor, cause the processor to: triage a panel of patients based on the priority value.What is claimed is:

Claims

CLAIMS1. A method for controlling a medical device, comprising: receiving, by a processor of a medical device, from one or more processors of one or more respiratory care devices, a plurality of data sets, each data set corresponding to a current alarm; querying, by the processor, a database comprising one or more a priority values, each priority value corresponding to at least one alarm; assigning, by the processor, a priority value to each received alarm; and displaying, on a graphical user interface (GUI), the alarms in order of priority.

2. The method of claim 1, comprising displaying only the alarm with the highest priority value.

3. The method as in any one of claims 1-2, comprising displaying two or more current alarms wherein each alarm comprises a graphical element with a different color.

4. The method as in any one of claims 1-3, comprising displaying the current alarms on a sorted list in descending order.

5. The method as in any one of claims 1-4, comprising displaying a record of past alarms.

6. The method of claim 5, comprising displaying two or more past alarms wherein each alarm comprises a graphical element with a different color.

7. The method as in any one of claims 5-6, comprising displaying the past alarms on a sorted list in descending order.

8. The method as in any one of claims 1-7, comprising displaying information on how to resolve each alarm.

9. The method as in any one of claims 1-8, comprising receiving, from one or more processors of one or more respiratory care devices that data indicating that an alarm has been resolved and removing resolved alarms from the GUI.

10. A method for controlling a medical device, comprising: receiving, by a processor of a medical device, one or more data sets, each data set comprising setting values for operating a respiratory care device; transmitting, by the processor of the medical device, to one or more processors of one or more respiratory care devices, the one or more data sets, updating, by the one or more processors of one or more respiratory care devices, the settings of the one or more respiratory care devices, and delivering, by the one or more respiratory care devices, a breathing gas to a patient under updated operating conditions based on the received setting values.

11. The method of claim 10, wherein the medical device is a remote device electronically connected to the respiratory care device via an internet data connection.

12. The method of as in any one of claims 10-11, wherein the settings include one or more of gas temperature, gas humidity, FiO2, and / or flow rate.

13. The method of as in any one of claims 10-12, wherein the settings include one or more alarm limits.

14. The method of as in any one of claims 10-13, comprising receiving, by the processor of the medical device, data comprising a user identification and updating the settings only if the user identification matches a stored value.

15. The method of as in any one of claims 10-14, wherein the patient’s vital signs are remotely monitored following a setting update.

16. The method of claim 15, wherein the settings are reverted to previous values if the desired effect of the settings change is not achieved.

17. A method for controlling a medical device, comprising: receiving, by a processor of a medical device, from one or more processors of one or more respiratory care devices, data comprising respiratory care device operation information and, from one or more processors of patient device, patient data comprising symptom information, and displaying, on a graphical user interface (GUI), the operation information and symptom information.

18. The method of claim 17, wherein the symptom information is received daily.

19. The method as in any one of claims 17-18 wherein the symptom information is received from one or more mobile devices via SMS.

20. The method as in any one of claims 17-19, wherein communication between the devices is encrypted.

21. The method as in any one of claims 17-20, comprising causing, by the processor of the medical device, transmittal of a text message to one or more to remind a user to transmit symptom information.

22. The method as in any one of claims 17-21, comprising displaying, on the GUI, patient symptom changes and recommended actions to take.

23. The method as in any one of claims 17-22, comprising querying, by the processor, a database comprising one or more a priority values, each priority value corresponding to a set of values comprising therapy compliance status, pulse oximetry readings, active device alarms, disposables lifecycle, and / or other information; assigning, by the processor, a priority value to a set of symptoms; and displaying, on a graphical user interface (GUI), the symptoms in order of priority.

24. The method of claim 23, comprising triaging a panel of patients based on the priority value.

25. A system for respiratory care, comprising: at least one processor electronically coupled to a medical device for respiratory care; and a memory electronically coupled to the at least one processor, the memory containing a set of instructions, wherein the instructions, when executed by the processor, cause the processor to: receive, by a processor of the medical device, from one or more processors of one or more respiratory care devices, a plurality of data sets, each data set corresponding to a current alarm; query, by the processor, a database comprising one or more a priority values, each priority value corresponding to at least one alarm; assign, by the processor, a priority value to each received alarm; and display, on a graphical user interface (GUI), the alarms in order of priority.

26. The system of claim 25, wherein the set of instructions, when executed by the processor, cause the processor to: display only the alarm with the highest priority value.

27. The system as in any one of claims 25-26, wherein the set of instructions, when executed by the processor, cause the processor to: display two or more current alarms wherein each alarm comprises a graphical element with a different color.

28. The system as in any one of claims 25-27, wherein the set of instructions, when executed by the processor, cause the processor to: display the current alarms on a sorted list in descending order.

29. The system as in any one of claims 25-28, wherein the set of instructions, when executed by the processor, cause the processor to: display a record of past alarms.

30. The system of claim 29, wherein the set of instructions, when executed by the processor, cause the processor to: display two or more past alarms wherein each alarm comprises a graphical element with a different color.

31. The system as in any one of claims 29-30, wherein the set of instructions, when executed by the processor, cause the processor to: display the past alarms on a sorted list in descending order.

32. The system as in any one of claims 25-31, wherein the set of instructions, when executed by the processor, cause the processor to: display information on how to resolve each alarm.

33. The system as in any one of claims 25-32, wherein the set of instructions, when executed by the processor, cause the processor to: receive, from one or more processors of one or more respiratory care devices that data indicating that an alarm has been resolved and remove resolved alarms from the GUI.

34. A system for respiratory care, comprising: at least one processor electronically coupled to a medical device for respiratory care, and a memory electronically coupled to the at least one processor, the memory containing a set of instructions, wherein the instructions, when executed by the processor, cause the processor to: receive, by a processor of a medical device, one or more data sets, each data set comprising setting values for operating a respiratory care device; transmit, by the processor of the medical device, to one or more processors of one or more respiratory care devices, the one or more data sets, update, by the one or more processors of one or more respiratory care devices, the settings of the one or more respiratory care devices, and deliver, by the one or more respiratory care devices, a breathing gas to a patient under updated operating conditions based on the received setting values.

35. The system of claim 34, wherein the medical device is a remote device electronically connected to the respiratory care device via an internet data connection.

36. The system of as in any one of claims 34-35, wherein the settings include one or more of gas temperature, gas humidity, FiO2, and / or flow rate.

37. The system of as in any one of claims34-36, wherein the settings include one or more alarm limits.

38. The system of as in any one of claims 34-37, wherein the set of instructions, when executed by the processor, cause the processor to: receive, by the processor of the medical device, data comprising a user identification and update the settings only if the user identification matches a stored value.

39. The system of as in any one of claims 34-38, wherein the patient’s vital signs are remotely monitored following a setting update.

40. The system of claim 39, wherein the settings are reverted to previous values if the desired effect of the settings change is not achieved.

41. A system for respiratory care, comprising: at least one processor electronically coupled to a medical device for respiratory care, and a memory electronically coupled to the at least one processor, the memory containing a set of instructions, wherein the instructions, when executed by the processor, cause the processor to: receive, by a processor of a medical device, from one or more processors of one or more respiratory care devices, data comprising respiratory care device operation information and, from one or more processors of patient device, patient data comprising symptom information, and display, on a graphical user interface (GUI), the operation information and symptom information.

42. The system of claim 41, wherein the symptom information is received daily.

43. The system as in any one of claims 41-42, wherein the symptom information is received from one or more mobile devices via SMS.

44. The system as in any one of claims 41-43, wherein communication between the devices is encrypted.

45. The system as in any one of claims 41-44, wherein the set of instructions, when executed by the processor, cause the processor to: cause, by the processor of the medical device, transmittal of a text message to one or more to remind a user to transmit symptom information.

46. The system as in any one of claims 41-45, wherein the set of instructions, when executed by the processor, cause the processor to: display, on the GUI, patient symptom changes and recommended actions to take.

47. The system as in any one of claims 41-46, wherein the set of instructions, when executed by the processor, cause the processor to: query, by the processor, a database comprising one or more a priority values, each priority value corresponding to a set of values comprising therapy compliance status, pulse oximetry readings, active device alarms, disposables lifecycle, and / or other information; assign, by the processor, a priority value to a set of symptoms; and display, on a graphical user interface (GUI), the symptoms in order of priority.

48. The system of claim 47, wherein the set of instructions, when executed by the processor, cause the processor to: triage a panel of patients based on the priority value.

Images