Therapeutic gas delivery systems and operations

Abstract

A method for managing a gas delivery device by a server is provided. The method includes: receiving a request for pre-provisioning a serial number of a PCB from a manufacturing application executed at a manufacturer; providing the serial number and the test firmware to the manufacturer; providing product firmware to the manufacturing application for installation into the gas delivery device; receiving encrypted data from a gas delivery gateway, the gas delivery gateway configured to receive performance information from the gas delivery device; decrypting the encrypted data to obtain the performance information, and storing the performance information in a historical storage library; receiving one or more actions performed at the service application; recording each action in the one or more actions in the historical storage library; and providing at least one token or data to the service application for each of the one or more actions.

Description

Technical Field

[0001] The present disclosure relates to a method of managing a gas delivery device by a server. Background Art

[0002] Medical facilities may use therapeutic gases, such as nitric oxide (NO), for administration to patients. Systems and devices that deliver therapeutic gases often require maintenance and oversight to ensure their proper function. This is often a labor-intensive and time-consuming process. Therefore, there is a need for a therapeutic gas delivery system and operation that can improve the manufacture, maintenance, and operation of therapeutic gases, such as NO, and simplify the use of therapeutic gas delivery systems in medical facilities, thereby enabling medical facilities to perform their functions of providing medical care. Summary of the Invention

[0003] A method for managing a gas delivery device by a server is provided. The method may include: receiving a request for a serial number of a pre-assigned printed circuit board (PCB) from a manufacturing application executed at a manufacturer, wherein the PCB is integrated into the gas delivery device; providing the serial number and test firmware to the manufacturer, wherein the test firmware is configured to program a hardware device during manufacturing; providing product firmware to the manufacturing application for installation into the gas delivery device; receiving encrypted data from a gas delivery gateway, wherein the gas delivery gateway is configured to receive performance information from the gas delivery device, wherein the gas delivery device is configured to transmit information to the gas delivery gateway under predetermined circumstances; decrypting the encrypted data to obtain the performance information, and storing the performance information of the gas delivery device in a history repository; receiving one or more actions performed at a service application to service or analyze the gas delivery device; recording each of the one or more actions in the history repository; and providing at least one token or data to the service application for each of the one or more actions.

[0004] In one aspect, the method can further include receiving encrypted data from a mobile device configured to interface with the gas delivery device, wherein the gas delivery device is configured to transmit information to the gas delivery gateway under predetermined circumstances. In some aspects, the method can even further include decrypting the encrypted data to obtain the performance information, and storing the performance information of the gas delivery device in the history repository. The gas delivery device can be configured to identify one of the mobile device or the gas delivery gateway and provide the encrypted data based on whether gas is being delivered.

[0005] In some aspects, when the gas delivery device is delivering the gas, the gas delivery device can be configured to omit transmission of the encrypted data. In some aspects, when the gas delivery device is not in shutdown mode and is not delivering the gas, the gas delivery device can be configured to transmit the encrypted data over a long-range wireless area network. In other aspects, when the gas delivery device is in shutdown mode, the gas delivery device can be configured to transmit the encrypted data over a long-range wireless area network or a short-range wireless area network.

[0006] In one aspect, the method can further include detecting at least one communication failure of the gas delivery device and providing a recommendation for servicing the gas delivery device.

[0007] In some aspects, the method can further include providing a manifest to the manufacturing application for installation into the gas delivery device, wherein the manifest identifies components that can be replaced in the gas delivery device. The one or more actions can include an action of replacing a first component of the gas delivery device based on an expiration date or a failure.

[0008] In one aspect, the method may further include generating an updated manifest identifying a second component that replaces the first component, wherein the act of replacing the first component is stored in the history repository.

[0009] The present invention further provides a system for managing a gas delivery device by a server. The system may include a processor in communication with a memory. The memory may include instructions executable by the processor to receive a request for a serial number for a pre-configured printed circuit board (PCB) from a manufacturing application executed at a manufacturer, wherein the PCB is integrated into the gas delivery device; provide the serial number and test firmware to the manufacturer, wherein the test firmware is configured to program the hardware device during manufacturing; receive encrypted data from a gas delivery gateway, wherein the gas delivery gateway is configured to receive performance information from the gas delivery device, wherein the gas delivery device is configured to transmit information to the gas delivery gateway under predetermined circumstances; decrypt the encrypted data to obtain the performance information, and store the performance information of the gas delivery device in a history repository; receive one or more actions performed at a service application to service or analyze the gas delivery device; record each of the one or more actions in the history repository; and provide at least one token or data to the service application for each of the one or more actions.

[0010] On the one hand, the memory including instructions executable by the processor can be further configured to: receive the encrypted data from a mobile device, the mobile device being configured to interface with the gas delivery device, wherein the gas delivery device is configured to transmit information to the gas delivery gateway under predetermined circumstances; and decrypt the encrypted data to obtain the performance information, and store the performance information of the gas delivery device in the historical repository.

[0011] In one aspect, the gas delivery device can be configured to identify one of the mobile device or the gas delivery gateway and provide the encrypted data based on whether gas is being delivered. In another aspect, when the gas delivery device is delivering the gas, the gas delivery device can be configured to omit transmission of the encrypted data. In another aspect, when the gas delivery device is not in shutdown mode and is not delivering gas, the gas delivery device can be configured to transmit the encrypted data over a long-range wireless area network. In another aspect, when the gas delivery device is in shutdown mode, the gas delivery device can be configured to transmit the encrypted data over a long-range wireless area network or a short-range wireless area network.

[0012] In one aspect, the memory including instructions executable by the processor can be further configured to detect at least one communication failure of the gas delivery device and provide a recommendation for servicing the gas delivery device. In one aspect, the memory including instructions executable by the processor can be further configured to provide a checklist to the manufacturing application for installation into the gas delivery device, wherein the checklist identifies components that can be replaced in the gas delivery device. In one aspect, the one or more actions can include an action of replacing a first component of the gas delivery device based on an expiration date or a failure.

[0013] In various aspects, the memory including instructions executable by the processor may be further configured to generate an updated manifest identifying a second component that replaces the first component, wherein the act of replacing the first component is stored in the history repository. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The details of one or more aspects of the subject matter described in the present disclosure are set forth in the following drawings and description. However, the drawings illustrate only some typical aspects of the present disclosure and therefore should not be considered to limit the scope of the present disclosure. Other features, aspects, and advantages will become apparent from the description, drawings, and claims.

[0015] Figure 1 An operational block diagram illustrating nitric oxide (NO) gas delivery operations according to aspects of the present disclosure is shown;

[0016] Figure 2 A block diagram illustrating a field deployment of a medical gas delivery system deployed in a medical facility according to aspects of the present disclosure is shown;

[0017] Figure 3A shows a detailed block diagram of a NO gas delivery system according to aspects of the present disclosure;

[0018] Figure 3B Shown Figure 3A Part of the detailed block diagram;

[0019] Figure 3C Shown Figure 3A Part of the detailed block diagram;

[0020] Figure 3D Shown Figure 3A Part of the detailed block diagram;

[0021] Figure 3E Shown Figure 3A Part of the detailed block diagram;

[0022] Figure 4 A sequence diagram illustrating the fabrication of a main printed circuit board (PCB) for a therapeutic gas delivery device that may be used in a therapeutic gas delivery system according to aspects of the present disclosure is shown;

[0023] Figure 5 A sequence diagram illustrating the fabrication of at least a portion of a gas delivery device that may be used in a therapeutic gas delivery system according to aspects of the present disclosure;

[0024] Figure 6 is a flow chart of an example method of therapeutic gas operation according to aspects of the present disclosure; and

[0025] Figure 7 An example of a system for implementing certain aspects of the present technology is shown. DETAILED DESCRIPTION

[0026] Medical facilities can use therapeutic gases for a variety of purposes. One exemplary gas is nitric oxide (NO). The disclosed systems and techniques disclose a therapeutic gas delivery system and operations that can improve the manufacture, maintenance, and operation of therapeutic gases, such as NO, and simplify the use of therapeutic gas delivery systems in medical facilities, enabling medical facilities to perform their functions of providing medical care.

[0027] Figure 1A block diagram of operations for manufacturing, servicing, and maintaining a therapeutic gas delivery device according to various aspects of the present disclosure is presented. The manufacture of a therapeutic gas delivery device includes obtaining various materials from external suppliers and manufacturers. The materials may include, for example, mechanical housings, circuit boards, tubing, wiring, and various other materials and components. The materials may be provided by multiple manufacturers and suppliers. Although Figure 1 Three manufacturers are shown, namely Manufacturer X 110, Manufacturer Y 112, and Manufacturer Z 114, but it should be understood that the components and materials used to manufacture the therapeutic gas delivery device may require more or fewer manufacturers and external service providers to provide. The therapeutic gas delivery operation includes various suppliers and manufacturers of various materials (such as mechanical housings, circuit boards), which are provided to a factory / service center that is configured to assemble the various components (or devices) used for the therapeutic gas delivery operation. One example device is a gas delivery device for delivering gas to a patient to achieve various purposes. An example of a gas is nitric oxide (NO). For example, the gas delivery device can be used in an intensive care unit (ICU), a neonatal intensive care unit (NICU), a pediatric intensive care unit (PICU), or other areas of a hospital to assist in treating patients in need. Another device of the therapeutic gas delivery operation is a gas delivery gateway, which is configured to communicate with the provider of the therapeutic gas delivery operation and to implement data logging, security of any data to comply with various legal requirements, and other features disclosed herein.

[0028] The factory / service center may include a parts storage area 116, which stores various raw materials used to assemble the different components of the therapeutic gas delivery system; a device assembly section 102, which is used to assemble the various components; a storage section 104, which is used to store assembled and operational components for the therapeutic gas delivery system; a service center 106, which is used to service the components of the therapeutic gas delivery system; and a decommissioning section 108, which is used to decommission the various components. The factory / service center provides both assembly and maintenance of components. For example, the factory / service center may be operable to manufacture new therapeutic gas delivery devices or to maintain therapeutic gas delivery devices already in operation at a hospital. When a component of a therapeutic gas delivery device needs to be replaced, the factory / service center may send the replacement component to the hospital for self-installation, dispatch an operator with the replacement component to the hospital to install the replacement component, or receive the therapeutic gas delivery device from the hospital and replace the component at the device assembly section 102 or service center 106.

[0029] At the parts storage area 116, parts supplied by external suppliers and manufacturers are cataloged, invoiced and uniquely numbered. At the device assembly section 102, the device is assembled from a collection of parts from the parts storage area 116. When the device is assembled, the device is assigned a unique device identifier (UDI) that identifies it throughout the life cycle of the device. Although the components of the device can be replaced during the life cycle of the device, the UDI does not change. The components used in the device are recorded throughout the life cycle of the device and updated when replaced to maintain a complete historical record of every part that a particular device has ever contained. These historical records can provide information about the quality of parts received from manufacturers, a history of device usage and usage cycles of certain components in a particular device that can be used to determine maintenance time, and other valuable information about a particular device.

[0030] The storage section 104 stores an inventory of components for therapeutic gas delivery operations, such as gas delivery devices and gas delivery gateways, and also receives refurbished components from service centers for distribution. In some aspects, the factory / service center can be used to distribute new / repaired components to customers such as hospitals. Hospitals can store unused components, such as gas delivery devices or components (filter assemblies, sensor assemblies, circuit boards, sampling lines, tubing, or other components necessary for the normal operation of therapeutic gas delivery devices) until they are needed. When needed, the hospital can activate the gas delivery device to deliver gas to the patient. When the gas delivery device is moved to a medical delivery area such as an ICU, the gas delivery device is in "treatment" 120. The gas delivery device can have a standby state, in which gas may not be delivered to the patient, and can be configured to deliver gas to the patient. In some aspects, the hospital may also include a hospital storage area 118, which is used to store the therapeutic gas delivery device until it is needed. The various states of the gas delivery device will be further described below.

[0031] During assembly at the device assembly section 102, a series of steps are performed to pre-configure the device for future use. For example, device firmware is uploaded to the device, and device-specific information is retrieved from the device for future use. Some of these steps may occur at the device level and / or at the component level. Pre-configuring a device for use is further described herein.

[0032] Each of the parties (e.g., external suppliers and manufacturers of various components for therapeutic gas delivery operations), the factory / service center, and the customer (e.g., a hospital) can be configured to connect to a dev / ops system, which is a combination of development and IT operations to provide continuous delivery, maintenance, and monitoring of high-quality software and hardware components. In some aspects, the dev / ops system includes a central server for managing various devices and coordinating with various systems, such as storage systems, enterprise resource planning (ERP) systems, authentication systems, etc.

[0033] When the device is located in a factory or service center, it can be considered to be in a "secure" environment and is allowed to accept connections from service and / or manufacturing applications. Once the device is "in the field" (e.g., a hospital), it can only transmit data under certain limited conditions and time frames (e.g., outbound communication, meaning it is the initiator of all communications).

[0034] Figure 2 A block diagram of a field deployment of a gas delivery system deployed in a medical facility according to various aspects of the present disclosure is shown. Specifically, system 200 includes a medical facility having different areas where one or more gas delivery devices 202 can be deployed or stored. For example, the medical facility includes an ICU 210, a nursing unit (CU) 220, and a storage area 230. In this case, the storage area 230 stores components that are not yet in use. The medical facility may also include an electronic device 240 (e.g., a mobile device such as a tablet, mobile phone, etc.) and a gas delivery gateway 250. Figure 2 As shown, there may be multiple gas delivery gateways 250 .

[0035] In some aspects, the electronics 240 and the gas delivery gateway 250 can be configured to receive data recorded by one or more gas delivery gateways 250. In some cases, a medical facility can have a single gas delivery gateway 250 that communicates with the electronics 240 and / or the dev / ops system 260.

[0036] During the time that the gas delivery device 202 is deployed to a medical facility, the gas delivery device maintains communication with the dev / ops system 260 via wireless transmissions on a periodic and therapy-based basis. These communications can occur through the gas delivery gateway 250, or through local wireless transmissions initiated by a field agent at the medical facility site using an application on an electronic device 240 (e.g., a mobile phone, tablet, etc.) to collect data from the gas delivery device 202.

[0037] When a gas delivery device 202 is determined or reported to be faulty, or after a defined period of time has passed (i.e., scheduled maintenance), the gas delivery device is removed from the medical facility and returned to the factory / service center. During this service, the gas delivery device is inspected and components are replaced if faults exist or if they have reached (or are nearing) end-of-life (e.g., sensors, batteries, etc.). If necessary, new product firmware can be loaded, and all historical data (typically log files) from the gas delivery device 202 can be retrieved and deleted so that the gas delivery device can be redeployed to a different hospital than the one from which it was retrieved.

[0038] Throughout the lifecycle of gas delivery device 202 lies dev / ops system 260, which houses business logic, ecosystem monitoring, device management, and medical / customer management software stacks. All components of gas delivery device 202, gas delivery device 202 itself, and its service, deployment, and operational history are tracked and managed within dev / ops system 260.

[0039] In some aspects, the gas delivery device 202 is configured to transmit data to the electronic device 240 during transitions between "standby" periods and "therapy" periods. In therapy (e.g., participating in the treatment of a patient, whether actively delivering NO or ready to deliver NO), the gas delivery device 202 may remain in this state for several days or even weeks, after which it is returned to a "standby" state, in which it is typically removed from the vicinity of the patient requiring treatment, possibly cleaned, and then placed in a defined storage area for future use.

[0040] In certain circumstances, the gas delivery device 202 is permitted to transmit wirelessly, such as during a defined time-limited window and when the gas delivery device 202 is not actively delivering NO to the patient. When the gas delivery device 202 is in a standby state, the gas delivery device 202 can transmit over both a long-range wireless access network (LoraWAN) and a short-range wireless network (e.g., Bluetooth Low Energy (BLE)). When the gas delivery device 202 is in a therapy state but not actively delivering NO, the gas delivery device 202 is permitted to use LoRaWAN again, subject to transmission window restrictions. When the gas delivery device 202 is delivering NO, the gas delivery device 202 may not transmit over any protocol at all.

[0041] There is another scenario where the gas delivery device 202 is installed in a medical facility that does not have any co-located gateway, such as the electronic device 240, or the gas delivery device 202 is unable to autonomously communicate with the electronic device 240 as intended. In this scenario, a person will travel to the hospital with the electronic device 240 running the corresponding application, and BLE can be used as a mechanism to collect any pending data transmissions from the gas delivery device 202 in standby mode, thereby triggering a transmission to the electronic device 240 via Wi-Fi.

[0042] In some aspects, there may be multiple co-located gas delivery gateways 250 and the gas delivery device 202 may be configured to ensure data is only provided once. Various aspects may be implemented to ensure data is successfully retrieved by the electronic device 240 or the gas delivery gateway 250 .

[0043] A gas delivery gateway 250 can be deployed at each hospital along with the gas delivery devices 202 to collect information and act as a router for transmissions from the gas delivery devices 202, thereby collecting transmissions via various communication technologies such as LoRaWAN and / or Wi-Fi. The data is collected and sent to a server for decryption and verification. In some aspects, the gas delivery gateway 250 can use a cellular (3G / 2G) uplink from the gas delivery gateway 250 to the server.

[0044] If there are multiple gas delivery gateways 250 in a medical facility, for example due to transmission / reception issues caused by the construction and / or layout of the hospital, each gas delivery gateway 250 will be configured to collect data in a similar manner from each gas delivery device 202 in the medical facility. The gas delivery device 202 will repeatedly attempt to send any unsent data (within its transmission standard and over an allowed radio frequency band) until the first gas delivery gateway 250 confirms that it has been received, at which point the gas delivery device 202 will consider the data sent and will not attempt to send it again.

[0045] In this scenario, i.e., if the gas delivery gateway 250 is not deployed, the gas delivery gateway 250 is faulty, or the gas delivery device 202 is out of range of the gas delivery gateway 250 at any point in time, the untransmitted data remains on the gas delivery device 202 until it is collected (and confirmed) by a corresponding electronic device 240 running, for example, BLE / Wi-Fi for communication. In some cases, a representative (agent / employee) will travel to the medical facility, locate the gas delivery device 202 from which the server has not received any transmissions for an extended period of time, and initiate a data transfer from the gas delivery device 202. The application on the electronic device 240 will then upload the received data to the server, if possible, depending on network or cellular capabilities.

[0046] The application on the electronic device 240 can also retrieve the consolidated data at the gas delivery gateway 250 in the event that the gas delivery device 202 has successfully transmitted to the gas delivery gateway 250, but the uplink from the gas delivery gateway 250 to the server is not functioning properly. This can prevent a representative from searching the hospital for the gas delivery device 202, which may be located on many different floors or departments.

[0047] Figure 3A A detailed block diagram of a dev / ops system 300 according to various aspects of the present disclosure is shown. Specifically, Figure 3A The various components required to implement the security, data storage, data retrieval, and other functions described herein are shown. For example, the dev / ops system 300 may include various communication points for sending and receiving data. The dev / ops system 300 integrates all functions involved in the management and manufacture of therapeutic gas delivery devices deployed in hospitals, including the processes of device manufacturing, servicing, data transmission collection from the hospital, and billing.

[0048] The device usage server 322 and the device manufacturing server 328 (collectively referred to as the device servers) may be operable to record the parts and components delivered after manufacturing and before assembly into devices. The device servers may further be operable to track the specific components in each device and generate an inventory for each device during manufacturing and service operations. The device servers may further be operable to provide configuration data to be written to each device during manufacturing and service operations. The device servers may further be operable to populate deployment configuration information into the field gateway to enable the field gateway to receive data from the devices deployed to its location. The device servers may further be operable to receive transmitted data from devices in the field, decrypt the data, and verify the validity and integrity of the data. The device servers may further be operable to derive expiration and activation dates for user-replaceable components in the devices (e.g., gas sensor modules). The device servers may further be operable to identify which specific devices or entire hospitals do not appear to be transmitting data regularly or reliably. The device server may further be operable to ensure that all interactions and operations performed on the device by the service or factory program are logged and tracked. The device server may further be operable to generate the data required to facilitate the use of the mobile application to collect the logs from the device via BLE / Wi-Fi.

[0049] The device server can have interfaces with multiple external components and resources, including system applications and products (SAP) (hospital data, device deployment, and bill generation), log repositories, factory applications, service center applications, configuration management databases (e.g., Azure SQL), mobileiron (mobile device application management), firmware image repositories (image locations for software, upgrade packages, etc.), and IoT interfaces (Azure IoTHub) for receiving wireless transmissions from devices and provisioning deployments to field gateways and mobile applications.

[0050] The core components of the dev / ops system 300 are the device usage server 322 and the device manufacturing server 328. The device usage server 322 may include an IoT hub interface 324 and a mobile application provisioning module 326. The device usage server 322 may communicate with various modules, such as Figure 3A As shown. For example, the device usage server 322 can communicate with a device located in the hospital 301. The device firmware 306 can be configured to transmit data to the electronic device (mobile device 304), and the mobile device can transmit the data to the IoT hub interface 324 through the IoT hub 320. The mobile device 304 can also communicate with the Trusted 302. The device identity management module 308 can communicate with the mobile application provisioning module 326 and the device usage server 322. The device identity management module 308 can be configured to verify the identity of the mobile device 304, thereby ensuring security. The user management module 310 can be configured to communicate with the device usage server 322 and the device manufacturing server 328.

[0051] The service center 303 can communicate with the device manufacturing server through the device firmware 312 and the service application 314. The service application allows firmware to be uploaded to the device firmware 312 and the firmware data to be transmitted to the device manufacturing server 328. This can provide various information to the device usage server 322 through the user management module 310 to ensure that all parts in the device are properly tracked and monitored.

[0052] The factory 305 can communicate with the device manufacturing server 328 through the device manufacturing firmware 316 and the factory application 318. The factory application 318 can allow firmware to be uploaded to the manufacturing firmware 316 during device manufacturing and transmit the firmware data to the device manufacturing server 328. This can provide various information to the device usage server through the user management module 310 to ensure that all parts in the device are properly tracked and monitored.

[0053] The device usage server may communicate with the enterprise resource planning module 348. The enterprise resource planning module 348 may be configured to store hospital configuration information, such as the structure of the hospital and the devices.

[0054] The device manufacturing server 328 may also communicate with a device parts inventory management module 330. The device parts inventory management module 330 may include a MAC address management module 332. The device parts inventory module 330 may be configured to store data related to various components in inventory for use in devices during service or manufacturing.

[0055] The device manufacturing server 328 may also communicate with a configuration management database 334 (Azure SQL). The configuration management database 334 may be configured to securely track the identities of various components used in the manufacturing and servicing of devices, and to manage the components.

[0056] The dev / ops system 300 may further include a deployment data repository 338 and a firmware image repository 336 in communication with the device manufacturing server 328. The deployment data repository 338 may store and transmit configuration data for deploying devices in the hospital. The firmware image repository 336 may be configured to store and transmit data related to the versions of firmware in various devices.

[0057] The dev / ops system 300 can further include a log analysis module 342. The log analysis module 342 can be configured to determine the proper function of a device or a specific component in a device. The log analysis module 342 can receive data from the device manufacturing server 328 via the log repository 340, including data related to components in the device. The log analysis module 342 can also receive data related to device usage from the device usage server 32 via the log repository 346. In some instances, the data received by the log analysis module 342 is pre-processed (e.g., to decrypt the data or perform other functions) by the log pre-processor module 344 before being received by the log analysis module 342.

[0058] Figure 3B A detailed diagram of a portion of a dev / ops system 300 is shown. In some examples, device firmware 306 in a hospital 301 can communicate with a mobile device 304 via BLE. In another example, the device firmware 306 can communicate with a field gateway 350 via WiFi. The mobile device 304 can communicate with an IoT hub 320 via MQTTS, which communicates with an IoT hub interface 324 of a device usage server via AMQPS, thereby providing device usage data to the device usage server 322. In another example, the device firmware 306 can communicate with a field gateway 350, which sends data to the IoT hub 320 via a cellular connection, and thereby to the IoT hub interface 324 and the device usage server. The mobile device 304 can connect to Trusted 302 via the internet.

[0059] The device identity management module 308 may communicate over HTTPS (DDI) with both the device manufacturing server 328 and the device usage server 322. The device identity management module 308 may be a device gateway mobile application.

[0060] Figure 3C A detailed diagram of a portion of a dev / ops system 300 is shown. In a service center 303, device firmware can communicate with a service application 314 via Ethernet. Service application 314 can be a PC application. Service application 314 can transmit data to a device manufacturing server 328 via HTTPS. In a factory 305, device manufacturing firmware 316 can communicate with a factory application 318 via Ethernet. Factory application 318 can be a PC application. Factory application 318 can transmit data to a device manufacturing server 328 via HTTPS. Factory application 318 can include a complete set of service and factory application features.

[0061] The user management module 310 may include user accounts, authenticator accounts, console accounts, and permission settings. The user management module 310 may communicate with both the device usage server 322 and the device manufacturing server 328. In some instances, the device usage server may include a user console 352 for communicating with the user management module 310.

[0062] The device manufacturing server 328 can communicate with a device part inventory management module 330, which can include a MAC address management module 332. The device part inventory management module 330 can include data such as device part serial numbers, firmware versions, software versions, and bills of materials. The MAC address module 332 can include MAC addresses for various device parts.

[0063] Figure 3D A detailed diagram of a portion of the dev / ops system 300 is shown. In some examples, the device usage server 322 can communicate with the device HQ 354, the SQL database 356, and the customer care dashboard 358. The device HQ 354 can be configured to deliver gateway configurations to the dev / ops system and monitor and control the manufacturing, production, and provisioning of devices and components. The SQL database 356 can be configured to report on gas usage, device activity, cylinder (gas cylinder used with the device) usage, and field devices. The customer care dashboard 358 can be configured to provide scheduled preventative maintenance for the device, contracts, customers, cylinder usage, last communication date for the device, and gas usage data.

[0064] The enterprise resource planning module 348 can provide the hospital configuration, structure, and structure of the equipment to the equipment usage server 322. In some instances, the enterprise resource planning module 348 can be prohibited from receiving usage data.

[0065] Figure 3E A detailed diagram of a portion of a dev / ops system 300 is shown. A device configuration management database 334 can be written to and / or updated (based on whether a new device is manufactured or an existing device is serviced). The configuration management database 334 can store device (module) data, including part numbers, device (module) identifiers, hardware and firmware versions, and serial numbers for each device and each component.

[0066] The deployment data repository 338 can store information such as the hospital's communication structure (WiFi, LoRa, BLE), a product code whitelist, the hospital's location, and the hospital's time zone. The deployment data repository 338 can store this data for multiple different hospitals using the device. The firmware image repository 336 can store information used for version management of various devices and device components.

[0067] A device may consist of several PCBs and assemblies, which may be manufactured by multiple suppliers. Each part may be tested post-manufacturing and may be assigned a unique serial number that identifies the part during its existence. Certain components may require provisioning and / or retrieval of unique data or information for other parts of the life cycle. For example, a NO-use board may have its physical identifiers (e.g., Wi-Fi and BLE MAC addresses, LoRaWAN DEVEUI) collated and stored along with a unique serial number to provide a lookup capability that maps the device identity to these fields. The dev / ops system 300 may record these serial numbers and attributes when the part is received by the factory.

[0068] During device assembly, a set of parts and components are assembled to create a device. During this phase, the device is assigned a UDI that does not change throughout the device's lifecycle. Unique data (e.g., encryption keys) is provisioned during this step. The encryption keys are created and provisioned by the dev / ops system, which also securely stores them for future use. A device manifest is loaded into the device, enabling it to verify that the correct board is installed, ensuring the integrity of the device.

[0069] A configuration file that configures the radio for wireless transmission within the hospital is also loaded, so that no further interaction is required when the device is deployed to the hospital. This configuration includes the LoRaWAN credentials, the Wi-Fi access point to join and its credentials, the Wi-Fi band, and BLE configuration settings. The product firmware is installed, replacing any manufacturing software that was installed on the individual boards during the manufacturing process.

[0070] When devices are deployed to hospitals, they are not pre-configured or pre-assigned to a specific hospital before delivery. Any device can potentially be delivered to any hospital. Sometimes, it may be necessary to provide additional configuration or customization for a device in certain circumstances for certain hospitals. Specific configurations for different geographic regions can include a default language, time offset, and a list of allowed cylinder codes.

[0071] When a device is delivered to the hospital, its UDI and / or serial number is recorded as delivered to the hospital, and this information is recorded in the dev / ops system 300. The recorded information is used to enable the device server to facilitate wireless transmissions from the device in the hospital to the dev / ops system 300.

[0072] When in the hospital, the device switches between standby and therapy periods. The device may remain in therapy mode (i.e., participating in the treatment of a patient) for days or even weeks, i.e., actively delivering therapeutic gases or ready to deliver therapeutic gases. The device is allowed to transmit wirelessly in certain circumstances, during a defined time limit window, and only when the device is not actively delivering therapeutic gases to the patient. When in standby mode, the device can transmit via Wi-Fi or LoRaWAN and act as a BLE server. When the device is in therapy mode but not actively delivering therapeutic gases, it is only allowed to use LoRaWAN within the transmission window limits. When the device is delivering therapeutic gases, it cannot make any transmissions via any radio protocol.

[0073] There is also a second scenario where the device is installed in a hospital without any field gateway, or the device is unable to communicate with the field gateway autonomously. In this scenario, the operator will go to the hospital with a mobile device running a mobile app and can use BLE as a mechanism to collect any pending transmissions from the device in standby mode, thereby triggering a transmission to the mobile device via Wi-Fi.

[0074] Devices must be retrieved from hospitals regularly and undergo preventive maintenance as scheduled by the regional service center. There may also be instances where a device requires service outside of scheduled maintenance (e.g., to repair a damaged component or upgrade a part). While at the service center, the device is serviced and can be deployed to the same hospital or a different one.

[0075] At the service center, the log file is downloaded from the device and uploaded to the device server, and after the log file is successfully received and verified, the device server approves the deletion of the log file from the device storage. If any board or component needs to be replaced, the device server generates an updated inventory file that is stored in the device.

[0076] Part of the log files downloaded from the device includes a history of all messages the device has used to transmit over LoRaWAN / Wi-Fi since the last service operation. These log files are also made available to the device server to ensure that no data loss occurs.

[0077] Figure 4 A sequence diagram is shown for manufacturing a main printed circuit board (PCB) for a gas delivery device that can be used in a therapeutic gas delivery system according to aspects of the present disclosure. In some cases, the sequence shows an operator 402 configuring a manufacturing application 406 (e.g., at a factory / service center) to provision PCB 404 with information needed to build a device (e.g., gas delivery device 202). In some aspects, PCB 404 is configured to receive information from a server 408, which builds test firmware and constructs a checklist for installing and building gas delivery device 202. Initially, operator 402 requests provisioning of a new device at manufacturing application 406, and manufacturing application 406 sends a serial number request 414 to PCB 404.

[0078] In response, PCB 404 sends serial number 416 to manufacturing application 406. Based on the serial number, server 408 provides test firmware request 418 to server 408, which then creates test firmware 426 at block 424. In some aspects, the test firmware includes proprietary information, such as a generation key that is programmed into gas delivery device 202. Server 408 sends test firmware 426 to manufacturing application 406, which transfers test firmware 426 to PCB 404. At block 428, PCB 404 writes test firmware 426 to a non-volatile storage medium, such as flash memory or EEPROM.

[0079] Figure 5 A sequence diagram illustrating the fabrication of at least a portion of a gas delivery device that may be used in a therapeutic gas delivery system according to aspects of the present disclosure is presented.

[0080] Specifically, in Figure 5, a server 502, a manufacturing application 504, and a gas delivery device 506 (e.g., gas delivery device 202) are configured to program artifacts and other information into the respective devices to enable communication in a secure manner. In some aspects, the manufacturing application 504 is configured to send a serial number request 510 requesting serial numbers for various components of the gas delivery device 506. For example, because the gas delivery device 506 is configured to deliver gas for medical use, the gas delivery device 506 may include multiple components, such as actuators (e.g., actuators, valves, etc.) for activating the therapeutic gas, a wireless communication module, etc. The gas delivery device 506 provides a device serial number 512 to the manufacturing application 504, and the device serial number 512 is then transmitted to the server 502. In some instances, the device serial number 512 may also include serial numbers or other identifying information for one or more gas sources connected to the gas delivery device.

[0081] At block 514, 506 is configured to process the information and generate various artifacts 516 to be installed into the gas delivery device 506. The artifacts may include a device key binary (populated into the mainboard's EEPROM), a device inventory file, a unique device identifier (UDI) file, a device ID file including the device serial number, a wireless transmission profile and certificate file, a set of allowed NOx gas cylinder product codes, and language and time offset settings files.

[0082] The workpiece is transferred to the manufacturing application 504 and then programmed into the gas delivery device 506. At this point, the device is configured for provisioning into a production state by installing the production firmware. At this point, the manufacturing application 504 sends a firmware request 518 to the server 502 for the latest production firmware and receives the production firmware 520. In some aspects, the dev / ops operations are configured to ensure that the firmware 520 is only provided over a secure channel and is provided to known clients using existing and future security technologies. The firmware is then provided by the manufacturing application 504 to the gas delivery device 506 and installed, overwriting the test firmware. At this point, the gas delivery device 506 has all the operating software, but further steps such as testing phase, packaging, etc. may be performed.

[0083] Figure 6 An example method 600 for a dev / ops system according to aspects of the present disclosure is presented. Although the example method 600 depicts a particular order of operations, the order may be modified without departing from the scope of the present disclosure. For example, some of the depicted operations may be performed in parallel or in a different order without materially affecting the functionality of the method 600. In other examples, different components of an example device or system implementing the method 600 may perform functions at approximately the same time or in a particular order.

[0084] According to some examples, the method includes receiving a request to provision a printed circuit board (PCB) from a manufacturing application executing at a manufacturer at block 605. For example, Figure 7 The processor 710 shown can receive a request for pre-assigning a printed circuit board (PCB) from a manufacturing application executing at a manufacturer. The PCB is integrated into the gas delivery device. The PCB can also provide a serial number to the manufacturing application.

[0085] According to some examples, the method includes providing the test firmware to the manufacturer at block 610. For example, Figure 7 The processor 710 shown can provide test firmware to manufacturers. The test firmware is configured to program the hardware device during manufacturing.

[0086] According to some examples, the method includes providing the manifest to a manufacturing application at block 615 to install the manifest into the gas delivery device. Figure 7 The processor 710 shown can provide a manifest to a manufacturing application to install the manifest into the gas delivery device. The manifest identifies components that can be replaced in the gas delivery device.

[0087] According to some examples, the method includes providing product firmware to a manufacturing application at block 620 for installation into a gas delivery device. Figure 7 The illustrated processor 710 may provide product firmware to a manufacturing application for installation into a gas delivery device.

[0088] According to some examples, the method includes receiving encrypted data from a gas delivery gateway at block 625, the gas delivery gateway being configured to receive performance information from a gas delivery device. Figure 7 The processor 710 shown may receive encrypted data from a gas delivery gateway configured to receive performance information from a gas delivery device. The gas delivery device is configured to transmit information to the gas delivery gateway under predetermined circumstances.

[0089] According to some examples, the method includes receiving encrypted data from a mobile device at block 630, the mobile device being configured to interface with a gas delivery device. Figure 7The processor 710 shown can receive encrypted data from a mobile device that is configured to interface with the gas delivery device. The gas delivery device is configured to transmit information to the gas delivery gateway under predetermined circumstances. The gas delivery device is configured to identify one of the mobile device or the gas delivery gateway and provide encrypted data based on whether gas is being delivered. In some aspects, at box 630, when the gas delivery device is not in shutdown mode and is not delivering gas, the gas delivery device is configured to transmit the encrypted data over a long-range wireless area network. In other aspects, at box 630, when the gas delivery device is in shutdown mode, the gas delivery device is configured to transmit the encrypted data over a long-range wireless area network or a short-range wireless area network. In some aspects, when the gas delivery device is delivering gas, the gas delivery device is configured to omit the transmission of the encrypted data.

[0090] According to some examples, the method includes, at block 635, decrypting the encrypted data to obtain performance information and storing the performance information of the gas delivery device in a history repository. Figure 7 The illustrated processor 710 may decrypt the encrypted data to obtain the performance information and store the performance information of the gas delivery device in a history repository.

[0091] According to some examples, the method includes, at block 640, decrypting the encrypted data to obtain performance information and storing the performance information of the gas delivery device in a history repository. Figure 7 The illustrated processor 710 may decrypt the encrypted data to obtain the performance information and store the performance information of the gas delivery device in a history repository.

[0092] According to some examples, the method includes detecting at least one communication failure of the gas delivery device at block 645. For example, Figure 7 The illustrated processor 710 may detect at least one communication failure of the gas delivery device.

[0093] According to some examples, the method includes providing a recommendation for servicing the gas delivery device at block 650. For example, Figure 7 The processor 710 shown may provide recommendations for servicing the gas delivery device.

[0094] According to some examples, the method includes receiving one or more actions performed at a service application to service or analyze a gas delivery device at block 655. For example, Figure 7 The illustrated processor 710 can receive one or more actions to be performed at a service application to service or analyze a gas delivery device. The one or more actions include an action to replace a first component of the gas delivery device based on an expiration date or a failure.

[0095] According to some examples, the method includes recording each of the one or more actions in a history repository at block 660. For example, Figure 7 The illustrated processor 710 may record each of the one or more actions in a history repository.

[0096] According to some examples, the method includes providing at least one token or data to the service application for each of the one or more actions at block 665. Figure 7 The illustrated processor 710 may provide at least one token or data to the service application for each of the one or more actions.

[0097] According to some examples, the method includes generating an updated manifest at block 670, the updated manifest identifying a second component that replaces the first component. Figure 7 The illustrated processor 710 may generate an updated manifest identifying the second component that replaces the first component.The act of replacing the first component is stored in a history repository.

[0098] Figure 7 An example of a computing system 700 is shown, which can be, for example, any computing device that makes up the various parts of a gas delivery system, or any component thereof in which the components of the system communicate with each other using connection 705. Connection 705 can be a physical connection through a bus, or directly connected to processor 710, such as in a chipset architecture. Connection 705 can also be a virtual connection, a network connection, or a logical connection.

[0099] In some embodiments, computing system 700 is a distributed system in which the functionality described herein can be distributed across a data center, multiple data centers, a peer-to-peer network, and the like. In some embodiments, one or more of the system components described herein represent multiple such components, each of which performs some or all of the functionality described for the component. In some embodiments, a component can be a physical device or a virtual device.

[0100] The example system 700 includes at least one processing unit (CPU or processor) 710 and connections 705 that couple various system components, including system memory 715, such as read-only memory (ROM) 720 and random access memory (RAM) 725, to the processor 710. The computing system 700 may include a cache 712 of high-speed memory that is directly connected to the processor 710, in close proximity to the processor, or integrated as part of the processor.

[0101] Processor 710 may include any general-purpose processor and hardware or software services, such as services 732, 733, and 736 stored in storage 730, configured to control processor 710, which is a specialized processor that incorporates software instructions into the actual processor design. Processor 710 may be a substantially fully self-contained computing system containing multiple cores or processors, a bus, a memory controller, a cache, etc. Multi-core processors may be symmetric or asymmetric.

[0102] To enable user interaction, the computing system 700 includes an input device 725, which can represent any number of input mechanisms, such as a microphone for voice, a touch screen for gesture or graphic input, a keyboard, a mouse, motion input, voice, etc. The computing system 700 may also include an output device 735, which can be one or more of a variety of output mechanisms known to those skilled in the art. In some cases, a multimodal system can enable a user to provide multiple types of input / output to communicate with the computing system 700. The computing system 700 may include a communication interface 720, which generally controls and manages user input and system output. There is no limitation on the operation of any particular hardware structure, and therefore, the basic features herein can be easily replaced as improved hardware or firmware structures are developed.

[0103] The storage device 730 may be a non-volatile memory device and may be a hard disk or other type of computer-readable medium that can store computer-accessible data, such as a magnetic tape cassette, a flash memory card, a solid-state memory device, a digital versatile disk, a magnetic tape cassette, random access memory (RAM), read-only memory (ROM), and / or some combination of these devices.

[0104] Storage 730 may include software services, servers, services, etc. that, when the code defining such software is executed by processor 710, cause the system to perform a certain function. In some embodiments, hardware services that perform a particular function may include software components stored in a computer-readable medium connected to the necessary hardware components (e.g., processor 710, connection 705, output device 735, etc.) to perform the function.

[0105] For clarity of explanation, in some cases, the present technology may be presented as including a single functional block including a device, device component, step or routine in a method embodied in software or a combination of hardware and software.

[0106] Any of the steps, operations, functions or processes described herein may be performed or implemented by a combination of hardware and software services, or performed or implemented individually, or performed or implemented in combination with other devices. In some embodiments, a service may be software residing in a memory of a client device and / or in one or more servers of a content management system, and when a processor executes the software associated with the service, one or more functions are performed. In some embodiments, a service is a program or a set of programs that performs a specific function. In some embodiments, a service may be considered a server. The memory may be a non-transient computer-readable medium.

[0107] In some embodiments, computer-readable storage devices, media, and memories may include wired or wireless signals containing bit streams, etc. However, when referred to, non-transitory computer-readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and signals themselves.

[0108] The method according to the above-mentioned example can be implemented using computer-executable instructions stored on a computer-readable medium or otherwise available. Such instructions can include instructions and data that, for example, enable a general-purpose computer, a special-purpose computer or a special-purpose processing device to perform a certain function or a group of functions or otherwise configure a general-purpose computer, a special-purpose computer or a special-purpose processing device to perform a certain function or a group of functions. The various parts of the computer resources used can be accessed through a network. Executable computer instructions can be, for example, binary, intermediate format instructions (such as assembly language), firmware or source code. The example of a computer-readable medium that can be used to store instructions, information used and / or information created during the method based on the example includes a disk or optical disk, a solid-state memory device, a flash memory, a USB device with a non-volatile memory, a network storage device, etc.

[0109] Devices implementing methods based on these disclosures may include hardware, firmware, and / or software and may be implemented in any of a variety of form factors. Typical examples of such form factors include servers, laptops, smartphones, small form factor personal computers, personal digital assistants, and the like. The functions described herein may also be implemented in external devices or add-in cards. By way of further example, such functions may also be implemented by different chips on a circuit board or by different processes executed in a single device.

[0110] Instructions, media for transmitting such instructions, computing resources for executing the instructions, and other structures for supporting such computing resources are all means for providing the functionality described in these disclosures.

[0111] Specific details are provided in the above description to provide a comprehensive understanding of the embodiments and examples provided herein, but those skilled in the art will recognize that the present application is not limited thereto. Therefore, although the illustrative embodiments of the present application have been described in detail herein, it should be understood that the creative concepts can be embodied and used differently in other ways, and unless limited by the prior art, the appended claims are intended to be interpreted as including such variations. The various features and aspects of the above-mentioned applications can be used alone or in combination. In addition, the embodiments can be used in any number of environments and applications beyond those described herein without departing from the broader scope of this specification. Therefore, the description and drawings should be regarded as illustrative rather than restrictive. For illustrative purposes, the method is described in a particular order. It should be understood that in alternative embodiments, the method can be performed in an order different from the order described.

[0112] For clarity of explanation, in some cases, the present technology can be presented as including a single functional block, which includes a functional block of a device, device component, step or routine in a method embodied in the form of software or a combination of hardware and software. In addition to the components shown in the drawings and / or described herein, other components can also be used. For example, circuits, systems, networks, processes and other components can be shown as components in block diagram form so as not to obscure the embodiments in unnecessary details. In other cases, well-known circuits, processes, algorithms, structures and techniques can be shown without unnecessary details to avoid obscuring the embodiments.

[0113] In addition, it will be understood by those skilled in the art that the various illustrative logic blocks, modules, circuits, and algorithmic steps described in conjunction with the various aspects disclosed herein can be implemented as electronic hardware, computer software, or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Technicians can implement the functionality in different ways for each specific application, but such implementation decisions should not be interpreted as resulting in departure from the scope of this disclosure.

[0114] The various embodiments described above may be described as processes or methods, which may be depicted as flow charts, flowcharts, data flow diagrams, structure diagrams, or block diagrams. Although a flow chart may describe operations as a sequential process, many operations may be performed in parallel or simultaneously. In addition, the order of the operations may be rearranged. When the operations of a process are completed, the process terminates, but may have additional steps not included in the accompanying drawings. A process may correspond to a method, function, procedure, subroutine, subprogram, etc. When a process corresponds to a function, the termination of the process may correspond to the function returning to the calling function or main function.

[0115] The process and method according to the above-mentioned example can be implemented using computer-executable instructions stored on a computer-readable medium or otherwise available. Such instructions may include, for example, instructions and data that enable a general-purpose computer, a special-purpose computer or a processing device to perform a certain function or a group of functions or otherwise configure a general-purpose computer, a special-purpose computer or a processing device to perform a certain function or a group of functions. The various parts of the computer resources used can be accessed through a network. Computer-executable instructions can be, for example, binary, intermediate format instructions (such as assembly language), firmware, source code. The example of a computer-readable medium that can be used to store instructions, information used and / or information created during the method based on the example includes a disk or optical disk, a flash memory, a USB device with a non-volatile memory, a network storage device, etc.

[0116] In some embodiments, computer-readable storage devices, media, and memories may include wired or wireless signals containing bit streams, etc. However, when referred to, non-transitory computer-readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and signals themselves.

[0117] Those skilled in the art will understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the foregoing description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof, depending in part on the specific application, the desired design, the corresponding technology, etc.

[0118] Various exemplary logic blocks, modules, and circuits related to the aspects disclosed herein may be implemented or executed using hardware, software, firmware, middleware, microcode, hardware description language, or any combination thereof, and may take any of a variety of form factors. When implemented in software, firmware, middleware, or microcode, program code or code segments for performing the necessary tasks (e.g., a computer program product) may be stored in a computer-readable or machine-readable medium. A processor may perform the necessary tasks. Examples of form factors include laptops, smartphones, mobile phones, tablet devices, or other small form factor personal computers, personal digital assistants, rack-mounted devices, stand-alone devices, and the like. The functions described herein may also be embodied in external devices or add-in cards. By way of further example, such functions may also be implemented on a circuit board by different chips or by different processes executed in a single device.

[0119] Instructions, media for transmitting such instructions, computing resources for executing the instructions, and other structures for supporting such computing resources are all example ways of providing the functionality described in this disclosure.

[0120] The techniques described herein may also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques may be implemented in any of a variety of devices, such as a general-purpose computer, a wireless communication device handset, or an integrated circuit device with multiple uses, including applications in wireless communication devices handsets and other devices. Any features described as modules or components may be implemented together in an integrated logic device, or individually as discrete but interoperable logic devices. If implemented in software, the techniques may be implemented at least in part by a computer-readable data storage medium containing program code that includes instructions for performing one or more of the methods, algorithms, and / or operations described above when executed. The computer-readable data storage medium may form part of a computer program product that may include packaging material. The computer-readable medium may include a memory or data storage medium, such as a random access memory (RAM), such as a synchronous dynamic random access memory (SDRAM), a read-only memory (ROM), a non-volatile random access memory (NVRAM), an electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, and the like. Additionally or alternatively, the technology may be implemented at least in part by a computer-readable communication medium that carries or transmits program code in the form of instructions or data structures and that can be accessed, read, and / or stored.

[0121] The program code can be executed by a processor, which may include one or more processors, such as one or more DSPs, general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuit systems. Such processors can be configured to perform any of the techniques described in this disclosure. A general-purpose processor can be a microprocessor, but in an alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Therefore, as used herein, the term "processor" can refer to any of the aforementioned structures, any combination of the aforementioned structures, or any other structure or device suitable for implementing the techniques described herein.

[0122] Those skilled in the art will understand that the less than ("<") and greater than (">") symbols or terms used in this document may be replaced with less than or equal to ("≤") and greater than or equal to ("≥") symbols, respectively, without departing from the scope of this specification.

[0123] When a component is described as being “configured to” perform certain operations, such configuration may be accomplished by, for example, designing electronic circuits or other hardware to perform the operations, by programming programmable electronic circuits (e.g., a microprocessor or other suitable electronic circuits) to perform the operations, or any combination thereof.

[0124] The phrases “coupled to” or “communicatively coupled to” refer to any component that is physically connected, directly or indirectly, to another component, and / or any component that is in communication with another component (e.g., connected to the other component via a wired or wireless connection and / or other applicable communication interface).

[0125] Claim language or other language reciting “at least one of” a set and / or “one or more” a set indicates that one member of the set or multiple members of the set (in any combination) satisfy the claim. For example, claim language reciting “at least one of A and B” or “at least one of A or B” means A, B, or A and B. In another example, claim language reciting “at least one of A, B, and C” or “at least one of A, B, or C” means A, B, C; or A and B; or A and C; or B and C; or A, B, and C. The language “at least one of” a set and / or “one or more” a set does not limit the set to the items listed in the set. For example, claim language reciting “at least one of A and B” or “at least one of A or B” may mean A, B, or A and B, and may additionally include items not listed in the set of A and B.

[0126] As used herein, the terms "medical gas" and "therapeutic gas" may be used interchangeably to refer to a gas administered to a patient in need thereof, other than the unmodified breathing gas from a ventilator.

[0127] The disclosure shown and described above is merely an example. While many of the features and advantages of the present technology, as well as details of the structure and function of the present disclosure, have been set forth in the foregoing description, the present disclosure is illustrative only, and variations in detail, particularly in the shape, size, and arrangement of parts, may be made within the principles of the present disclosure to the greatest extent indicated by the broad, general meanings of the terms used in the appended claims. It will be understood, therefore, that the examples described above may be modified within the scope of the appended claims.

Claims

1. A method for managing a gas delivery device by a server, the method comprising: receiving a request from a manufacturing application executed at a manufacturer for a serial number for a pre-assigned printed circuit board (PCB), wherein the PCB is integrated into the gas delivery device; providing the serial number and test firmware to the manufacturer, wherein the test firmware is configured to program the hardware device during manufacturing; providing product firmware to the manufacturing application for installation into the gas delivery device; receiving encrypted data from a gas delivery gateway, the gas delivery gateway being configured to receive performance information from the gas delivery device, wherein the gas delivery device is configured to transmit information to the gas delivery gateway under predetermined circumstances; decrypting the encrypted data to obtain the performance information, and storing the performance information of the gas delivery device in a history repository; receiving one or more actions performed at a service application to service or analyze the gas delivery device; recording each of the one or more actions in the history repository; as well as At least one token or data is provided to the service application for each of the one or more actions.

2. The method according to claim 1, further comprising: receiving the encrypted data from a mobile device, the mobile device configured to interface with the gas delivery device, wherein the gas delivery device is configured to transmit information to the gas delivery gateway under predetermined circumstances; and The encrypted data is decrypted to obtain the performance information, and the performance information of the gas delivery device is stored in the history repository. 3 . The method of claim 2 , wherein the gas delivery device is configured to identify one of the mobile device or the gas delivery gateway and provide the encrypted data based on whether gas is being delivered.

4. The method according to claim 3, wherein: When the gas delivery device is delivering the gas, the gas delivery device is configured to omit transmission of the encrypted data.

5. The method according to claim 2, wherein: When the gas delivery device is not in the off mode and is not delivering gas, the gas delivery device is configured to transmit the encrypted data over a long-range wireless area network.

6. The method according to claim 2, wherein: When the gas delivery device is in the off mode, the gas delivery device is configured to transmit the encrypted data over a long-range wireless area network or a short-range wireless area network.

7. The method of claim 1, further comprising: detecting at least one communication failure of the gas delivery device; and Recommendations for servicing the gas delivery device are provided.

8. The method of claim 1, further comprising: A manifest is provided to the manufacturing application for installation into the gas delivery device, wherein the manifest identifies components that can be replaced in the gas delivery device.

9. The method of claim 8, wherein the one or more actions include an action of replacing a first component of the gas delivery device based on an expiration date or a failure.

10. The method according to claim 9, further comprising: An updated manifest is generated that identifies a second component that replaces the first component, wherein the act of replacing the first component is stored in the history repository.

11. A system for managing a gas delivery device by a server, the system comprising: a processor in communication with a memory, the memory comprising instructions executable by the processor to: receiving a request from a manufacturing application executed at a manufacturer for a serial number for a pre-assigned printed circuit board (PCB), wherein the PCB is integrated into the gas delivery device; providing the serial number and test firmware to the manufacturer, wherein the test firmware is configured to program the hardware device during manufacturing; receiving encrypted data from a gas delivery gateway, the gas delivery gateway being configured to receive performance information from the gas delivery device, wherein the gas delivery device is configured to transmit information to the gas delivery gateway under predetermined circumstances; decrypting the encrypted data to obtain the performance information, and storing the performance information of the gas delivery device in a history repository; receiving one or more actions performed at a service application to service or analyze the gas delivery device; recording each of the one or more actions in the history repository; and At least one token or data is provided to the service application for each of the one or more actions.

12. The system of claim 11 , wherein the memory comprising instructions executable by the processor is further configured to: receiving the encrypted data from a mobile device, the mobile device configured to interface with the gas delivery device, wherein the gas delivery device is configured to transmit information to the gas delivery gateway under predetermined circumstances; and and The encrypted data is decrypted to obtain the performance information, and the performance information of the gas delivery device is stored in the history repository.

13. The system of claim 12, wherein the gas delivery device is configured to identify one of the mobile device or the gas delivery gateway and provide the encrypted data based on whether gas is being delivered.

14. The system according to claim 13, wherein: When the gas delivery device is delivering the gas, the gas delivery device is configured to omit transmission of the encrypted data.

15. The system according to claim 12, wherein: When the gas delivery device is not in the off mode and is not delivering gas, the gas delivery device is configured to transmit the encrypted data over a long-range wireless area network.

16. The system of claim 12, wherein: When the gas delivery device is in the off mode, the gas delivery device is configured to transmit the encrypted data over a long-range wireless area network or a short-range wireless area network.

17. The system of claim 11, wherein the memory comprising instructions executable by the processor is further configured to: detecting at least one communication failure of the gas delivery device; and Recommendations for servicing the gas delivery device are provided.

18. The system of claim 11, the memory including instructions executable by the processor further configured to provide a manifest to the manufacturing application to install the manifest into the gas delivery device, wherein the manifest identifies components that can be replaced in the gas delivery device.

19. The system of claim 18, wherein the one or more actions include an action of replacing a first component of the gas delivery device based on an expiration date or a failure.

20. The system of claim 19, wherein the memory comprising instructions executable by the processor is further configured to generate an updated manifest identifying a second component that replaces the first component, wherein the act of replacing the first component is stored in the history repository.

Images