Medical waste collection and disposal system

Abstract

A medical waste collection unit containing collected medical waste is docked with the docking station to form a fluid connection and a first data connection therebetween. A cleaning cycle is performed on the medical waste collection unit, in which a cleaning fluid is supplied from the docking station and sprayed into the waste collection unit, and waste material is expelled from the waste collection unit through the docking station. A status update indicating the docked status of the waste collection unit is communicated from the docking station to the remote processing system via the second data connection, and response notification data is received from the remote processing system at the docking station. The notification data indicates a maintenance notification to be displayed on the medical waste collection unit and is triggered by the docking station for display on the waste collection unit via the first data connection.

Description

[Technical Field]

[0001] The present invention relates to a medical waste collection and disposal system.

[0002] [Related Applications] This application claims priority to and the full benefit of U.S. Provisional Patent Application No. 63 / 419012, filed October 25, 2022, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0003] Waste collection devices are used in healthcare facilities to collect waste materials during medical procedures. Healthcare facilities often employ multiple such devices to accommodate the various procedures that occur in different parts of the facility. Routine maintenance and proper allocation of these devices is required to ensure efficient operation and utilization of the devices. Summary of the Invention

[0004] One or more computer systems can be configured to perform specific operations or actions by having software, firmware, hardware, or a combination thereof installed on the system that, when activated, causes the system to perform the actions. One or more computer programs can be configured to perform specific operations or actions by including instructions that, when executed by a data processing device, cause the device to perform the actions. One general aspect involves a method of maintaining a medical waste collection unit including a canister for collecting medical waste generated during a surgical procedure. The method includes transporting the medical waste collection unit with collected medical waste to a docking station, the docking station including a supply line coupled to a first interface for establishing a fluid supply connection with the medical waste collection unit when docked with the docking station, a drain line coupled to a second interface for establishing a fluid drain connection with the medical waste collection unit when docked with the docking station, a first communication interface for establishing a first data connection with the medical waste collection unit when docked with the docking station, and a second communication interface for establishing a second data connection with a remote processing system. The method also includes docking the medical waste collection unit to the docking station to form a fluid supply connection, a fluid discharge connection, and a first data connection. The method also includes performing a cleaning cycle at the medical waste collection unit, where cleaning fluid is supplied to the medical waste collection unit from the docking station supply line through the fluid supply connection and sprayed into the canister, and waste material is discharged from the canister through the fluid discharge connection to the docking station discharge line. The method also includes communicating a status update from the docking station to the remote processing system over the second data connection, the status update indicating the docked status of the medical waste collection unit.The method also includes receiving, at the docking station, notification data from the remote processing system responsive to the status update via the second data connection, the notification data indicating a maintenance notification to be displayed on the medical waste collection unit. The method also includes triggering, by the docking station, via the first data connection, the medical waste collection unit to display the maintenance notification based on the notification data. Other implementations of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the operations of the method.

[0005] One general aspect includes a method for maintaining a medical waste collection unit including a canister for holding medical waste generated during a surgical procedure. The method includes transporting the medical waste collection unit along with collected medical waste to a docking station, the docking station including a supply line coupled to a first interface for establishing a fluid supply connection with the medical waste collection unit when docked with the docking station, and a drain line coupled to a second interface for establishing a fluid drain connection with the medical waste collection unit when docked with the docking station. The method also includes docking the medical waste collection unit to the docking station to form the fluid supply and drain connections. The method also includes performing a cleaning cycle, in which a cleaning fluid is supplied from the docking station supply line through the fluid supply connection to the medical waste collection unit and sprayed into the canister, and waste material is discharged from the canister through the fluid drain connection to the docking station drain line. The method also includes tracking, by the one or more controllers, a cleaning cycle metric to determine whether to trigger a maintenance notification indicating running a cleaning cycle on the medical waste collection unit with the docking station. The method also includes resetting, by the one or more controllers, the cleaning cycle metric in response to running a cleaning cycle on the medical waste collection unit with the docking station. The method also includes identifying, by the one or more controllers, a notification threshold based on operational data of the medical waste collection unit, the operational data being indicative of medical waste collection unit surgical operation data and / or medical waste collection unit cleaning cycle data. The method also includes triggering, by the one or more controllers, display of a maintenance notification on the medical waste collection unit based on the cleaning cycle metric and the notification threshold.Other implementations of this aspect include corresponding computer systems, devices, and computer programs stored on one or more computer storage devices, each configured to perform the operations of the method.

[0006] One general aspect includes a method for managing a population of medical waste collection units, each of which includes a canister for holding medical waste. The method includes receiving, by a remote processing system remote from the medical waste collection units, first usage data from a first medical waste collection unit indicating a duration for which the first medical waste collection unit is activated to draw medical waste into the canister of the first medical waste collection unit using a vacuum source. The method also includes receiving, by the remote processing system, second usage data from a second medical waste collection unit indicating a duration for which the second medical waste collection unit is activated to draw medical waste into the canister of the second medical waste collection unit using a vacuum source. The method also includes comparing, by the remote processing system, the first usage data with the second usage data to determine relative usage data for the first medical waste collection unit and the second medical waste collection unit. The method also includes comparing, by the remote processing system, the relative usage data to a preset relative usage threshold. The method also includes triggering a usage notification in at least one of the first and second medical waste collection units based on the comparison. Other implementations of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the operations of the method.

[0007] One general aspect includes a method for managing a medical waste collection unit including a canister for holding medical waste and an aerosol removal unit including a filter. The method includes tracking, by one or more controllers, filter metrics to determine whether to indicate filter replacement based on operational data of the medical collection unit, the operational data being indicative of surgical data of the medical waste collection unit. The method also includes resetting, by the one or more controllers, the filter metrics in response to a filter replacement event. The method also includes triggering, by the one or more controllers, the display of a maintenance notice on a display of a personal computing device remote from the medical waste collection unit that instructs a user to replace the filter based on the filter metrics. Other implementations of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the operations of the method.

[0008] One general aspect includes a method for maintaining a medical waste collection unit including a canister for collecting medical waste materials generated during a surgical procedure. The method includes capturing, by an imaging device supported by a device cradle coupled to the canister, a video feed of the canister and waste materials disposed therein as a vacuum source of the medical waste collection unit draws the waste materials into the canister. The method also includes analyzing, by one or more controllers, multiple image frames of the video feed to identify visual data indicative of at least one of a degree of occlusion, a composition of the waste material, and a storage time of the waste material. The method also includes tracking, by the one or more controllers, metrics to determine whether to trigger a maintenance notification at the medical waste collection unit. The method also includes identifying, by the one or more controllers, a notification threshold based on the visual data. The method also includes triggering, by the one or more controllers, a maintenance notification at the medical waste collection unit based on the notification threshold and the metric. Other implementations of this aspect include corresponding computer systems, devices, and computer programs stored on one or more computer storage devices, each configured to perform the operations of the method. [Brief explanation of the drawings]

[0009] [Figure 1A] FIG. 1 illustrates an exemplary medical waste collection and disposal system including a medical waste collection unit for collecting medical waste during a surgical procedure and a docking station for emptying and cleaning the medical waste collection unit. [Figure 1B] FIG. 1 illustrates an exemplary aerosol removal unit of a medical waste collection unit. [Figure 2] FIG. 1 illustrates an exemplary system for maintaining a group of medical waste collection units that may be used by a healthcare system. [Figure 3]FIG. 1 illustrates another exemplary system for maintaining a group of medical waste collection units that may be used by a healthcare system. [Figure 4] FIG. 1 illustrates a medical waste collection system including a device cradle coupled to the medical waste collection unit and positioned to removably receive an imaging device for capturing images of the waste canister. [Figure 5] FIG. 1 illustrates an exemplary method for maintaining a fleet of medical waste collection units that may be used by a healthcare facility or system. [Figure 6A] 6 illustrates a graphical user interface (UI) that may be generated during the method of FIG. 5. [Figure 6B] 6 illustrates a graphical user interface (UI) that may be generated during the method of FIG. 5. [Figure 7] FIG. 1 illustrates another exemplary method for maintaining a fleet of medical waste collection units that may be used by a healthcare facility or system. [Figure 8] 4 shows an exemplary screen of a graphical user interface (GUI) that may be generated by the system of FIG. 2 or FIG. 3 to provide information about a population of medical waste collection units and associated docking stations. [Figure 9] FIG. 10 illustrates another exemplary screen of a GUI providing a detailed list of a population of medical waste collection units and associated docking stations. [Figure 10] FIG. 10 illustrates another exemplary screen of a GUI for displaying the status of a given medical waste collection unit. [Figure 11] FIG. 10 illustrates another exemplary screen of a GUI for displaying the status of a given docking station. [Figure 12] FIG. 10 illustrates another exemplary screen of a GUI for displaying a population summary of medical waste collection units. [Figure 13]FIG. 10 illustrates another exemplary screen of a GUI providing manifold usage data for a population of medical waste collection units. [Figure 14] FIG. 10 illustrates another exemplary screen of the GUI providing error code data for a population of medical waste collection units. [Figure 15] FIG. 10 illustrates another exemplary screen of a GUI providing filter data for a population of medical waste collection units. [Figure 16A] FIG. 10 illustrates an exemplary screen of a GUI providing return on investment data for a population of medical waste collection units. [Figure 16B] FIG. 10 illustrates an exemplary screen of a GUI providing return on investment data for a population of medical waste collection units. [Figure 17] FIG. 10 illustrates another exemplary screen of a GUI providing vacuum pump runtime data for a population of medical waste collection units. [Figure 18] FIG. 10 illustrates another exemplary screen of a GUI that provides a summary of docking stations associated with a population of medical waste collection units. [Figure 19] FIG. 10 illustrates another exemplary screen of a GUI providing cleaning cycle data for a population of medical waste collection units. [Figure 20] FIG. 10 illustrates another exemplary screen of a GUI providing facility disposer data for a population of medical waste collection units. DETAILED DESCRIPTION OF THE INVENTION

[0010] Aspects of the present disclosure generally relate to operating and maintaining mobile waste collection units, also referred to herein as rovers, utilized by healthcare facilities or systems to collect waste materials during medical procedures. A given healthcare facility or system may use multiple rovers in various locations and uses, and as a result, optimal maintenance schedules for the rovers may also vary. Rover management is therefore a difficult and complex task for administrators and clinical users alike, and if done improperly, can lead to suboptimal rover performance, increased service calls, and shortened rover lifespans.

[0011] As one non-limiting example, following a surgical procedure performed by a given rover, the rover may dock to a docking station to eject collected waste materials and perform a cleaning cycle on the rover. The docking station may be configured to perform various types of cleaning cycles (e.g., short wash cleaning cycles, normal wash cleaning cycles, long wash cleaning cycles) depending on the level of "cleaning" required. To thoroughly clean the rover and ensure its proper functioning, long cleaning cycles should be performed periodically, and rover components should be periodically evaluated and replaced. However, for a population of rovers with varying usage and locations, it is difficult to determine and ensure compliance with optimal maintenance schedules, including the performance of long cleaning cycles, for each rover, which may vary with respect to the rover's specific usage, and to efficiently manage rover usage with respect to the rover's estimated lifespan and maintenance schedule as a group.

[0012] The present disclosure provides systems and methods for overcoming these and other challenges presented by the use and maintenance of a fleet of rovers with varying usage and locations. As an example, the systems and methods described herein may be configured to implement a centralized management and notification service that dynamically updates maintenance and usage schedules for the fleet in real time and monitors the specific activity of each rover in the fleet and the activity of the fleet as a whole to promote both the longevity of individual rovers and efficient use of the fleet. The systems and methods may also be configured to generate notifications to personnel best suited to take action based on such monitoring, and aggregate data from multiple rovers to enable rapid and informed decision-making.

[0013] The systems and methods described herein are distinct from those conventional in the medical waste collection device art. Managing the use and maintenance of waste collection devices within a healthcare facility or system has traditionally been accomplished by noting the cleaning history of each device on a whiteboard or other physical tracking sheet, such as by noting the date, time, and device ID whenever a cleaning cycle occurs. However, given that a fleet of rovers is used in different locations, with different frequencies, and for different types of procedures within a healthcare facility or system, such techniques are inefficient. In particular, due to the transient nature of such devices, the written history may quickly become outdated or may become irrelevant, as healthcare personnel may be slow to update, review, and summarize such information between procedures. Aspects of the present disclosure help overcome the above challenges while minimizing any impact on the configuration or operation of the rovers by implementing a system that takes into account individual rover activity and the population as a whole to dynamically control in real time how the rovers are operated, such as by utilizing nearby mobile devices or docking stations to which the rovers can dock for cleaning as edge devices to communicate rover operational data to a central location.

[0014] 1A illustrates a medical waste collection and disposal system 100 for the collection and disposal of waste materials generated during medical procedures (e.g., surgical procedures) performed in a healthcare facility, such as a hospital. The waste materials may include bodily fluids, bodily tissue, irrigation fluids, and / or other materials that may be generated during various medical procedures. Often, medical procedures require large volumes of saline and / or other irrigation fluids to irrigate anatomical sites. As a result, the system 100 may be capable of handling large volumes of waste materials.

[0015] The system 100 may include a mobile waste collection unit 102, also referred to herein as a rover, and a generally fixed docking station 104. The rover 102 may be configured to collect waste materials generated during a medical procedure. The docking station 104 may function as a unit through which waste materials collected by the rover 102 are discharged for processing. The docking station 104 may also function for cleaning the rover 102, as described in more detail below. During use, the rover 102 may collect and store waste materials onboard until a user is ready to offload and discard the waste materials. In some implementations, the rover 102 may be capable of storing waste materials from a series of different medical procedures over a day or over several days without needing to offload the waste. Once the waste materials fill the rover 102 or the user is ready to discard the waste materials, the rover 102 may be wheeled by the user to the docking station 104. At the docking station 104, waste material may be emptied from the rover 102 into a waste drain or processing area, and the rover 102 may be cleaned for further use.

[0016] The rover 102 may include a cart 106 that provides mobility for the rover 102. The cart 106 may include a cart base 108 and a number of wheels 110 attached to the bottom of the cart base 108. A handle 112 may be attached to a vertical chassis 114 extending from the cart base 108 to facilitate movement of the rover 102 between use areas and between the use area and the docking station 104. Thus, a user may move the rover 102 within a healthcare facility to collect waste materials generated during medical procedures performed in different parts of the healthcare facility or system.

[0017] The rover 102 may also include one or more waste canisters 116, such as an upper waste canister 116A and a lower waste canister 116B, for collecting and temporarily storing waste materials during use. One or more vacuum pumps 118 may be supported on the cart base 108 and configured to provide suction at the waste canisters through one or more vacuum lines.

[0018] Suitable configurations and operation of the rover 102 subsystems may be disclosed in commonly owned U.S. Patent Application Publication No. 2005 / 0171495, WO 2007 / 070570, and WO 2014 / 066337, the disclosures of which are incorporated herein by reference in their entireties. Suitable configurations and operation of the rover 102 subsystems may also be disclosed in commonly owned WO 2017 / 112684, published June 29, 2017, the disclosure of which is incorporated herein by reference in its entirety.

[0019] The rover 102 may further include at least one receptacle 120 supported on the cart base 108. The receptacles 120 each define an opening 122 dimensioned to removably receive at least a portion of a manifold 124, such as a surgical waste collection manifold 124. FIG. 1 shows two receptacles 120, each associated with a different one of the plurality of waste canisters 116. In an alternative implementation, one receptacle 120 may be provided for all of the waste canisters 116. Each receptacle 120 may include a suction inlet configured to be disposed in fluid communication with the waste canister 116 associated with the receptacle 120. This may establish a suction path from a suction tube 126 disposed at the surgical site, through the manifold 124, to the waste canister 116 when removably inserted into the receptacle 120, thereby aspirating waste material from the surgical site into the waste canister 116. The manifolds 124 may be configured to prevent waste material from flowing back through the suction tubes 126 once the waste material has been collected by the rover 102. Each manifold 124 may also function to filter the waste material received from the suction tubes, such as to prevent clogging in the case of large particles. Some versions of the manifolds 124 may further include compartments for collecting and holding tissue specimens, such as for subsequent analysis.

[0020] The rover 102 may include a rover controller 128A configured to control the operation of the rover 102. To this end, the rover controller 128A may be in communication with the vacuum pump 118 and may be configured to regulate the on / off operation of the vacuum pump 118 and to regulate the degree of operation of the vacuum pump 118 to control the vacuum flow through the manifold 124. In some implementations, the rover controller 128A may include a processor 130A, a memory 132A, and a communication device 134A. The processor 130A may include one or more devices selected from a microprocessor, a microcontroller, a digital signal processor, a microcomputer, a central processing unit, a field programmable gate array, a programmable logic device, a state machine, a logic circuit, an analog circuit, a digital circuit, and / or any other device that processes signals (analog or digital) based on operating instructions stored in the memory 132A. Memory 132A may include one or more storage devices, including, but not limited to, read-only memory (ROM), random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, and / or any other device capable of storing information. Memory 132A may also include one or more persistent data storage devices, including, but not limited to, hard drives, optical drives, tape drives, non-volatile solid-state devices, and / or any other device capable of persistently storing information.

[0021] The processor 130A may be configured to implement the functions, features, and processes of the rover controller 128A described herein. More specifically, the processor 130A may operate under the control of software embodied in computer-executable instructions present in the memory 132A, which, when executed by the processor 130A, are configured to cause the processor 130A to perform the functions, features, and processes of the rover controller 128A described herein. The computer-executable instructions may be compiled or interpreted from a variety of programming languages ​​and / or technologies, including, but not limited to, Java, C, C++, C#, Objective-C, Fortran, Pascal, JavaScript, Python, Perl, and PL / SQL, alone or in combination. The memory 132A may also store data that can be accessed by, or more specifically, read by, the processor 130A to facilitate the functions, features, and processes of the rover controller 128A described herein.

[0022] The communication unit 134A may provide a machine interface that facilitates data communication between the rover controller 128A and one or more external systems and devices, such as other rovers 102, the docking station 104, a remote terminal, a nearby mobile device, or a remote server (e.g., a cloud service). The communication unit 134A may incorporate one or more wired and / or wireless technologies to facilitate such communication, including, but not limited to, Ethernet, USB, Wi-Fi, Bluetooth, and cellular. In some examples, due to the transient nature of the rover, the communication unit 134A of the rover controller 128A may be limited to relatively short-range and / or direct-connect communication technologies, or more specifically, relatively short-range and / or direct-connect wireless communication technologies, such as proximity-based wireless communication technologies (e.g., RFID, NFC), Bluetooth, Wi-Fi Direct, Zigbee, or LOS (line-of-sight) based wireless communication technologies (e.g., infrared (IR)). In other words, the communication device 134A may lack the relatively long-range communication capabilities, such as cellular and Wi-Fi, that enable connection with remote systems and devices over one or more computer networks. In some implementations, the communication device 134A may be coupled to an outward-facing IR transceiver 136 of the rover 102 to facilitate wireless communication with other devices, such as the docking station 104, using IR transmissions.

[0023] The rover 102 may also include a user interface 138A in operable communication with the rover controller 128A. The user interface 138A may be configured to provide a user with operational data related to the rover 102 and to receive user input for controlling the operation of the rover 102. For example, without limitation, the user interface 138A may include a display, one or more light-emitting diodes (LEDs), and / or a speaker for providing a user with operational data related to the rover 102. Additionally, the user interface 138A may include a touchscreen associated with the display to provide a graphical user interface (GUI) with user-selectable elements by which the user may input commands to adjust the operation of the rover 102, and / or may include one or more mechanically actuable input devices, such as buttons or dials, by which the user may input commands to adjust the operation of the rover 102. In some examples, the user interface 138A may also include a microphone for receiving voice commands from a user. In some examples, the user interface 138A may be provided by a tablet with a display that is removably mountable to the vertical chassis 114 of the rover 102 and that communicates with the rover controller 128A via the communication device 134A.

[0024] The rover 102 may further include a reader 140 disposed adjacent to each receptacle 120. Each reader 140 may be configured to communicate with an RFID tag 142 of a manifold 124 when the manifold 124 is inserted into the associated receptacle 120. The RFID tag 142 may be coupled to a surface, such as an inner or outer surface, of the manifold 124. The rover controller 128A may communicate with each reader 140 and be configured to instruct each reader 140 to periodically send a basic interrogation signal for the RFID tag 142. If the manifold 124 is not seated in a given receptacle 120, the reader 140 associated with the receptacle 120 may not receive a response to the basic interrogation signal. The vacuum pump 118 associated with a given receptacle 120 may be configured to prevent activation if the manifold 124 is not seated in the receptacle 120, or more specifically, if a compatible manifold 124 is not seated in the receptacle 120 (which may be determined based on reading data from the RFID tag 142 of the compatible manifold 124 when the manifold 124 is seated in the receptacle 120).

[0025] The rover 102 may also include an aerosol removal system 150, an expanded view of which is provided in FIG. 1B . The aerosol removal system 150 may be utilized to remove aerosols, such as smoke, from fluids, such as air, during a surgical procedure. The aerosol removal system 150 may include a conduit 152 and one or more inlets 154 in fluid communication with the conduit 152, such that fluid may be drawn into the conduit 152 through the inlets 154. The aerosol removal system 150 may further include an outlet 156 through which the fluid exits the conduit 152. The fluid drawn through the inlets 154 may be air carrying aerosols, such as smoke, generated during a medical procedure. A blower 158 of the aerosol removal system 150 may be in fluid communication with the conduit 152 to draw fluid into the inlets 154 and out the outlets 156 when the blower 158 is activated.

[0026] The aerosol removal system 150 may also include a filter 160 in fluid communication with the conduit 152. The filter 160 may be configured to filter one or more aerosols from the fluid flowing through the conduit 152 such that "clean" air is discharged through the outlet 156. For example, the filter 160 may include a filter such as a ULPA filter for filtering smoke generated during a surgical procedure. The filter 160 may preferably be supported by a filter housing including a filter enclosure and a filter cap to form a replaceable unit.

[0027] The aerosol removal system 150 may further include an aerosol sensor 162 in fluid communication with the conduit 152 and electrically connected to the rover controller 128A. The aerosol sensor 162 may be positioned in-line with the conduit 152 such that the fluid flowing through the conduit 152 may be sensed before passing through the filter 160. In other words, the aerosol sensor 162 may be upstream of the filter 160. The aerosol sensor 162 may be positioned within a filter enclosure and may also be replaceable along with the filter 160 to ensure accurate readings.

[0028] The aerosol sensor 162 may be configured to sense the presence and / or amount of one or more aerosols, such as smoke, passing through the conduit 152 and generate one or more sensor signals indicative of the presence and / or amount of each aerosol. The sensor signals may be communicated to the rover controller 128A. Based on the presence and / or amount of each aerosol indicated by the sensor signals, the rover controller 128A may be configured to track compliance with certain safety recommendations (e.g., surgical smoke removal), track the remaining life of the filter 160, and / or control operation of the blower 158. For example, the rover controller 128A may be configured to perform one or more of the above operations by tracking the duration that aerosols have been indicated to be present by the sensor signals.

[0029] As one non-limiting example, the aerosol sensor 162 may include at least one IR lamp for emitting IR light into the conduit 152 and at least one IR detector for sensing reflection of the emitted IR light by fluid moving through the conduit 152. The aerosol sensor 162 may then generate one or more sensor signals corresponding to the sensed reflection, which may then indicate the presence and / or amount of one or more aerosols moving through the conduit 152. The rover controller 128A may then be configured to evaluate the sensor signals to determine the presence and / or amount of one or more aerosols moving through the conduit 152. The aerosol sensor 162 may alternatively be implemented as another type of sensor, such as an electromagnetic sensor configured to sense an electromagnetic field from an aerosol detection cable positioned within the conduit 152 or near the surgical site, the aerosol detection cable configured to emit an electromagnetic field that varies depending on the presence and / or amount of aerosols, such as smoke, adjacent the cable.

[0030] Based on evaluation of the sensor signal, the rover controller 128A may be configured to vary the operation of the blower 158. For example, when the sensor signal indicates the absence of aerosols monitored in the conduit 152, the rover controller 128A may be configured to operate the blower 158 at a relatively low power level. That is, the blower 158 may be operated to provide just enough suction to draw fluid into the conduit 152 so that the aerosol(s), if present, can be sensed by the aerosol sensor 162.

[0031] During operation of the rover 102, the rover controller 128A may receive one or more sensor signals indicative of the respective presence and / or amount of one or more aerosols sensed in the conduit 152. When the rover controller 128A detects one or more aerosols in the conduit 152 based on the sensor signals, or more specifically, when it detects that the amount of aerosols in the conduit 152 is greater than a threshold amount, the rover controller 128A may be configured to increase operation of the blower 158 to a relatively high power level. This relatively high power level may be configured to quickly accelerate operation of the blower 158 (e.g., quickly accelerate rotation of the fan within the blower 158). After operating the blower 158 at the relatively high power level, the rover controller 128A may be configured to decrease the power level of the blower 158, such as to an intermediate power level that is higher than the relatively low power level and lower than the relatively high power level.

[0032] When operating at the intermediate power level, blower 158 may generate greater suction at inlet 154 than when blower 158 is operating at a relatively low power level. This allows aerosols, such as smoke, to be quickly evacuated (removed) from the surgical site and filtered by filter 160. While blower 158 is operating at the intermediate power level, aerosol sensor 162 may be configured to continue to evaluate the fluid passing through conduit 152 for one or more aerosols. In response to a sensor signal indicating the presence of each monitored aerosol in conduit 152 is less than a threshold amount or is not detected, rover controller 128A may be configured to return blower 158 to the relatively low power level and continue to evaluate the sensor signal for the presence of the monitored aerosol, as described above.

[0033] By operating blower 158 at a relatively low power level, the noise generated by blower 158 is significantly reduced, which helps maintain a quieter environment when delicate surgical procedures are being performed. However, by quickly ramping up to higher power levels, aerosol removal system 150 can maintain the performance level required to quickly evacuate (remove) aerosols from the surgical area. The power levels of blower 158 may be configurable by a user via user interface 138A. Additionally, or alternatively, blower 158 may be configured to operate at a constant power level throughout a surgical procedure, which may be changed by a user via user interface 138A.

[0034] 1A, the rover 102 may also include one or more particulate filters 164, such as a HEPA filter, in fluid communication with the waste canister 116 for filtering fluid (e.g., air) drawn into the waste canister 116 during collection of waste material from the surgical site. Like the filter 160, the particulate filter 164 may also be replaceable.

[0035] The rover 102 may also include one or more sensors 166 in communication with the rover controller 128A configured to generate operational data related to use of the rover 102. For example, without limitation, the sensors 166 may include a fluid measurement subsystem positioned to measure the volume of waste material received by the rover 102, or more specifically, each of the waste canisters 116, through the manifold 124 during a medical procedure and / or the volume of cleaning fluid received by the rover 102, or more specifically, each of the waste canisters 116, during a cleaning cycle. Additionally or alternatively, the sensors 166 may include one or more flow sensors to measure the flow rate of waste material passing through the manifold 124 during a medical procedure and / or cleaning fluid passing through the rover 102 during a cleaning cycle. Additionally or alternatively, the sensors 166 may include one or more blood concentration sensors to measure the concentration of blood in waste material passing through the manifold 124 during a medical procedure. Additionally or alternatively, the sensor 166 may include one or more temperature sensors for measuring the temperature of the cleaning fluid passing through the rover 102 during a cleaning cycle. An exemplary measuring or monitoring device is disclosed in commonly owned International Application No. PCT / US2021 / 058891, filed November 11, 2021, the entire contents of which are incorporated herein by reference.

[0036] As described above, the rover 102 may periodically dock with the docking station 104 to empty and / or clean the waste canister 116. Referring again to FIG. 1A , the docking station 104 may include a generally box-shaped metal cabinet 200. A plurality of guide rails 202 may extend from the front of the cabinet 200 to guide the rover 102 as it docks with the docking station 104. An off-load pump 204 may be disposed within the cabinet 200 and may be connected to a drain line 206 and to a waste coupler 208 through a waste line 210. The off-load pump 204 may be configured to pump waste material from the rover 102, through the waste coupler 208 and the waste line 210, into the drain line 206 when the rover 102 is docked with the docking station 104. The drain line 206 may extend from the off-load pump 204 to a waste treatment unit.

[0037] A water valve 212 may also be located within the cabinet 200. The water valve 212 may be connected to a water source for the healthcare facility via a supply line 214. For example, the water valve 212 may be connected to a hot water source, a cold water source, or any combination thereof. A water line 216 may extend from the water valve 212 to a water coupler 218. An injector 220 may be coupled to the water line 216 for injecting a cleaner into the water line 216. To this end, a container 222 of cleaner may be located outside the cabinet 200, with an intake line 224 of the injector 220 feeding into the container 222, such that when the container 222 is depleted, it can be replaced with a new container 222 of cleaner by simply moving the intake line 224 to the new container 222. The water valve 212 and injector 220 may be used to deliver cleaning fluid (e.g., water, with or without detergent) to the rover 102 through the water pipe 216 and water coupler 218 when the rover 102 is docked to the docking station 104.

[0038] The docking station 104 may also include a slidable cover 226 biased to be placed over the waste coupler 208 and the water coupler 218 to prevent debris from entering the waste line 206 and the water line 214 when the rover 102 is not docked to the docking station 104. When sufficient force is applied to the slidable cover 226, such as in the docking orientation by the rover 102 docked to the docking station 104, the slidable cover 226 may slide into the cabinet 200, thereby exposing the waste coupler 208 and the water coupler 218 for engagement with the drain and cleaning circuits of the rover 102, respectively.

[0039] The docking station 104 may further include a pair of docking receptacles 228 disposed on a forward-facing portion of the docking station 104. The rover 102 may have a corresponding pair of metal strike plates 230 disposed on a forward-facing portion of the rover 102. The docking receptacles 228 may be configured to receive the strike plates 230 to mate the rover 102 with the docking station 104 during docking. It will be appreciated that the strike plates 230 and the docking receptacles 228 may be interchangeable. In some implementations, the docking receptacles 228 may be electromagnetically actuatable to magnetically attach to the strike plates 230 when they are proximate to each other.

[0040] The docking station 104 may additionally include a docking station controller 128B. Similar to the rover controller 128A, the docking station controller 128B may be configured to manage the components of the docking station 104 when the rover 102 docks with the docking station 104, such as according to instructions from the rover controller 128A. More specifically, the docking station controller 128B may be operably coupled to the off-load pump 204, the water valve 212, and the injector 220, and receive data from and / or control each of these devices. Similar to the rover controller 128A, the docking station controller 128B may include a processor 130B, a memory 132B, and a communication device 134B, each of which may be configured similarly to that of the rover controller 128A described above. In other words, processor 130B may be configured to implement the functions, features, and processes of docking station controller 128B described herein, such as by executing software embodied by computer-readable instructions present in memory 132B. Memory 132B may store data accessed by, or more specifically, read by, processor 130B to facilitate the execution of such functions, features, and processes of docking station controller 128B described herein.

[0041] The communication device 134B of the docking station controller 128B may provide a machine interface that facilitates data communication between the docking station controller 128B and one or more external systems and devices. For example, in response to the rover 102 docking to the docking station 104, the communication device 134B of the docking station controller 128B may be configured to establish a connection with the communication device 134A of the rover controller 128A via a relatively short-range and / or direct connection wireless communication protocol, etc., to form a data connection between the docking station controller 128B and the rover controller 128A. In one example, the communication device 134B may be coupled to an IR transceiver 232 that is disposed in the docking station 104 such that the IR transceiver 232 and the IR transceiver 136 of the rover 102 are within line of sight (LOS) of each other when the rover 102 is docked to the docking station 104. The rover controller 128A may then communicate with the docking station controller 128B via the IR transceiver 136, 232 to select and initiate a particular type of cleaning cycle for the rover 102, exchange rover 102 operational data, and / or exchange notification data as described herein, etc.

[0042] In some implementations, the docking station 104 may be configured to function as an edge device for the rover 102 when docked with the docking station 104, such as via a data connection established with a remote processing system over one or more networks, including the Internet in some implementations. Thus, in response to receiving operational data from the rover controller 128A via the data connection formed between the communication devices 134A, 134B, the docking station controller 128B may be configured to communicate the received operational data to the remote processing system for processing in conjunction with operational data received from other rovers 102 utilized by the healthcare system and / or determine whether maintenance of usage-related notifications is appropriate for the rover 102. The communication device 134B of the docking station controller 128B may be configured to establish such a data connection using a relatively long-range communication technology, such as Ethernet, fiber, cellular, or Wi-Fi. As explained above, unlike the communication device 134B of the docking station 104, the communication device 134A of the rover 102 may lack long-range communication capabilities and / or internet access. As such, transmissions between the rover control device 128A and devices external to the rover 102 may be limited when the rover 102 is being operated to collect medical waste during a procedure and / or when not docked at the docking station 104, thereby avoiding potential intra-operative disruptions to or changes in the operation of the rover 102 caused by such data transmissions.

[0043] In some implementations, instead of or in addition to the docking station 104, other devices in the healthcare facility with relatively long-range network connectivity, such as a medical hub or a mobile personal computing device (e.g., a tablet), may be configured to serve as edge devices for the rover 102 when the rover 102 is near the device. More specifically, when the rover 102 comes within communication range of such other devices, the rover control device 128A may be configured to establish a wireless data connection with the device, such as using a relatively short-range and / or direct-connect wireless communication protocol, to enable the exchange of data therebetween. For example, in some implementations, a medical hub may be located outside but near the docking station 104, such that when the rover 102 is docked to the docking station 104, the rover control device 128A forms a wireless data connection with the hub. In some examples, the docking station control device 128B may maintain a data connection with the hub, which in turn may facilitate communication between the docking station 104 and the rover 102 when docked to the docking station 104, such as for triggering offload and cleaning cycles as described below.

[0044] Similar to the rover 102, the docking station 104 may include one or more sensors 234 in communication with the docking station controller 128B configured to generate operational data, or more specifically, cleaning cycle data, for the rover 102 docked thereto. More specifically, the sensors 234 may be configured to generate data indicative of characteristics of a drain cycle and / or cleaning cycle performed on the rover 102, including, but not limited to, at least one of water temperature data, water pressure data, detergent data, and cleaning cycle type data. For example, and without limitation, the sensors 234 may include a fluid measurement subsystem arranged to measure a volume of cleaning fluid delivered to the rover 102 during a cleaning cycle or drained from the rover 102 during a drain cycle. Additionally or alternatively, the sensors 234 may include one or more flow sensors for measuring the flow rate of cleaning fluid passing into the rover 102 during a cleaning cycle and / or from the rover 102 during a drain cycle. Additionally or alternatively, the sensors 234 may include one or more temperature sensors for measuring the temperature of the cleaning fluid passing into the rover 102 during a cleaning cycle.

[0045] When the rover 102 is ready to be emptied, it may be wheeled to the docking station 104 to connect (mate) with it. Guide rails 202 in the docking station 104 may guide the rover 102 as it moves toward the docking station 104 until the strike plate 230 engages with the receptacle 228. During such movement, the cart base 108 retracts the sliding cover 226 into the cabinet 200 of the docking station 104, thereby exposing the docking station couplers 208, 218. When the strike plate 230 engages with the receptacle 228, the docking station couplers 208, 218 may align with and mate with a set of corresponding couplers 236, 238 on the underside of the rover 102. More specifically, the docking station waste coupler 208 may couple to a corresponding waste coupler 236 of the rover 102 to allow waste material stored in the waste canister 116 to be conveyed to the drain line 206 via the off-load pump 204. The docking station water coupler 218 may similarly couple to a corresponding water coupler 238 of the rover 102 to transport cleaning fluid into the waste canister 116 of the rover 102 for cleaning the waste canister 116.

[0046] After waste material has been offloaded (removed) from the rover 102 to the drain line 206 during a drain cycle, cleaning may be initiated. To this end, the rover 102 may include a drain circuit comprising an upper waste line 240 extending between the upper waste canister 116A and the lower waste canister 116B for draining waste material from the upper waste canister 116A into the lower waste canister 116B. An upper waste valve 242 may be disposed in the upper waste line 240 and connected to the rover controller 128A to allow the flow of waste material from the upper waste canister 116A into the lower waste canister 116B.

[0047] The discharge circuit may further include a lower discharge line 244 extending from the lower waste canister 116B to the rover waste coupler 236 for discharging waste material in the lower waste canister 116B via the rover waste coupler 236 and the docking station 104 to the drain line 206. More specifically, the rover waste coupler 236 may be a dry-break coupling configured to prevent material from exiting the lower waste line 244 until coupled with the waste coupler 208 of the docking station 104, which may open the rover waste coupler 236, thereby allowing material to be pumped from the lower waste line 244 to the drain line 206 via the off-load pump 204.

[0048] In response to the rover 102 docking to the docking station 104, a user may instruct the rover controller 128A to initiate a discharge cycle to offload collected waste material, such as by interacting with a corresponding element of the user interface 138A of the rover 102. In response, the rover controller 128A may be configured to open the waste valve 242 to allow waste material to be discharged from the upper waste canister 116A to the lower waste canister 116B, and may trigger activation of the offload pump 204, such as by communicating a corresponding command to the docking station controller 128B via a data connection formed between the rover controller 128A and the docking station controller 128B as described above. In response to receiving such a command, the docking station controller 128B may be configured to operate the off-load pump 204 to pump waste material from the lower waste line 244, through the rover waste coupler 236, the docking station waste coupler 208, and the waste line 210, and ultimately to the drain line 206.

[0049] After the discharge cycle is performed, a cleaning cycle may be performed on the rover 102, such as according to the type of cleaning cycle option selected by the user. For example, the user interface 138A may be configured to provide various cleaning cycle options for user selection, such as a "short wash" cleaning option, a "normal wash" cleaning cycle option, and a "long wash" cleaning cycle option. The user's selection of a given type of cleaning cycle may be transmitted to the rover controller 128A, which may be configured to responsively trigger a cleaning cycle of the waste canister 116 according to the selected type of cleaning cycle, such as by communicating a corresponding instruction to the docking station controller 128B via a data connection formed therebetween. The rover controller 128A may be configured to automatically initiate a cleaning cycle of the waste canister 116 after the discharge cycle is completed (e.g., after the waste canister 116 is emptied of waste material), which may be determined by the rover controller 128A based on data generated by a sensor 166 located within or adjacent to the waste canister 116, based on data generated by a sensor 234 of the docking station 104, and / or based on the runtime (operating time) of the off-load pump 204.

[0050] In response to receiving the cleaning cycle command, the docking station controller 128B may be configured to open the water valve 209 and / or inject detergent from the container 222 into the water line 212 via the injector 220. The cleaning fluid may then flow through the docking station water coupler 218 and the rover water coupler 238 into a cleaning circuit on the rover 102, which may include a lower supply line 246 extending from the rover water coupler 238 to the lower waste canister 116B and an upper supply line 248 extending from the lower supply line 246 to the upper waste canister 116A. The lower supply solenoid valve 250 may be disposed in the lower supply line 246 between the lower canister 116B and the upper supply line 248, and the upper supply solenoid valve 252 may be disposed in the upper supply line 248 between the upper waste canister 116A and the lower supply line 246. The lower supply solenoid valve 250 and the upper supply solenoid valve 252 may be connected to and actuable by the rover controller 128A.

[0051] When a cleaning cycle begins, the rover controller 128A may be configured to open the upper supply solenoid valve 252, allowing cleaning fluid to flow under pressure from the lower supply line 246 to the upper supply line 248 and then to a sprinkler head located at the end of the upper supply line 248 for spraying over the interior of the upper waste canister 116A. In response to the cleaning fluid being sprayed in the upper waste canister 116A for a set spray time period, which may correspond to a currently selected cleaning cycle option, the rover controller 128A may be configured to close the upper supply solenoid valve 252 and open the lower supply solenoid valve 250 to spray the cleaning fluid over the interior of the lower waste canister 116B. In response to the cleaning fluid being sprayed in the lower waste canister 116B for the set spray time period, the rover controller 128A may then be configured to close the lower supply solenoid valve 250. During or after the cleaning fluid is sprayed into the waste canisters 116, the docking station controller 128B may be configured to operate the offload pump 204 to expel the dirty cleaning fluid from the upper and lower waste canisters 116 into the drain line 206 as described above.

[0052] In the example described above, the rover controller 128A may be configured to alternately open the lower supply solenoid valve 250 and the upper supply solenoid valve 252 to alternately spray the lower and upper waste canisters 116A, 116B. However, in other implementations, such as when sufficient water pressure is present, the rover controller 128A may be configured to simultaneously open the supply solenoid valves 250, 252 to simultaneously spray the waste canisters 116.

[0053] A given cleaning cycle performed on the rover 102 by the docking station 104 may include one or more wash phases and one or more rinse phases. During each wash phase, a detergent-containing solution (e.g., detergent-laden water) may be sprayed into the waste canister 116 for a set duration and then supplied by the docking station 104 to the rover 102 for draining as described above. Each wash cycle may be followed by a rinse phase, during which detergent-free water may be sprayed into the canister 116 for a set duration and then supplied by the docking station 104 to the rover 102 for draining as described above.

[0054] Different types of cleaning cycles may be associated with different durations for which the waste canister 116 is sprayed during each cleaning and / or rinsing phase of a cleaning cycle, and / or different numbers of cleaning and / or rinsing phases performed during a cleaning cycle. For example, when a "short clean" cleaning cycle is performed, the above-described cleaning and rinsing phases may each be performed relatively few times (e.g., each phase is performed once) and / or for a relatively short duration. When a "normal clean" cleaning cycle is performed, the above-described cleaning and rinsing phases may each be performed more times (e.g., each phase is repeated two or three times) and / or for a longer duration. Finally, when a "long clean" cleaning cycle is performed, the above-described cleaning and rinsing phases may each be performed even more times (e.g., each phase is repeated five or six times) and / or for a longer duration.

[0055] During each wash and rinse phase, the rover controller 128A may be configured to keep the waste valve 242 open and trigger operation of the off-load pump 204 to allow dirty cleaning fluid to be pumped into the drain line 206 simultaneously with the fluid spraying. Alternatively, in some implementations, when cleaning fluid is being sprayed into the waste canisters 116, the rover controller 128A may be configured to keep the waste valve 242 closed and / or stop operation of the off-load pump 204 until an event occurs, such as completing spraying each waste canister for a set duration.

[0056] In some implementations, when the waste valve 242 transitions from a closed state to an open state and / or when the off-load pump 204 transitions to an active state may depend on the type of cleaning cycle being performed. For example, without limitation, when a short or normal cleaning cycle is being performed, the rover controller 128A may be configured to keep the waste valve 242 open and the off-load pump 204 active throughout the wash and rinse phase to drain fluid from each waste canister 116 as the waste canister 116 is sprayed. Conversely, when a long cleaning cycle is being performed, the rover controller 128A may be configured to keep the waste valve 242 closed and / or the off-load pump 204 inactive for a set soak period after the end of spraying the waste canister 116 to soak each waste canister 116 for a period of time, which may be useful for removing additional dirt, caked-on dirt, or waste material from the waste canisters 116. Once the set soak period has expired, the rover controller 128A may be configured to open the waste valve 242 and / or enable operation of the off-load pump 204 to allow the dirty fluid to be pumped to the drain line 206 using the off-load pump 204.

[0057] In some implementations, a user may be able to customize parameters of a given cleaning cycle to be performed by the rover 102. More specifically, in response to the rover 102 docking to the docking station 104, the rover controller 128A may be configured to provide a GUI on the display of the user interface 138A that allows selection of one of the available cleaning cycle options for a subsequent cleaning cycle and also provides one or more user-selectable elements for customizing the parameters of the subsequent cleaning cycle. For example, without limitation, the one or more selectable elements may allow a user to set a cleaning cycle parameter such as a set spray duration, fill level, canister soak time, detergent volume, detergent addition timing, water pressure, water temperature, ingredient addition, or ultraviolet light activation. Additionally and / or alternatively, one or more of these parameters may be set using a remote user terminal 284 or mobile user device 286 (FIG. 2) in communication with the docking station 104 or rover 102, such as via one or more computer networks. In either case, in response to receiving inputs configuring one or more of the above-described cleaning cycle parameters, the controllers 128A, 128B may be configured to perform a cleaning cycle at the docked rover 102 in accordance with the inputs.

[0058] As explained above, a given healthcare facility or system may employ a fleet of rovers 102 (a fleet of rovers 102), each with various uses and locations. FIG. 2 illustrates an example of a rover management and notification system 280A that may be implemented to facilitate optimal maintenance and operation of the rovers 102 in a manner that was previously impractical. As shown in the illustrated example, the rover management and notification system 280A may include a plurality of rovers 102, at least one docking station 104 for performing drain and cleaning cycles on the rovers 102, at least one remote server 282, at least one remote user terminal 284, and at least one mobile user device 286. Each of these components may be capable of communicating with the other components via one or more computer networks 288. To this end, unlike the examples described above, the multiple rovers 102 in this example may include relatively long-range communication capabilities to establish data connections with a remote server 282 via a computer network 288, for example, without establishing relatively short-range data connections with a docking station 104 or nearby mobile user devices 286. The computer network 288 may incorporate wireless and / or wired technology and may include, without limitation, one or more local area networks (LANs), metropolitan area networks (MANs), and / or wide area networks (WANs) such as the Internet.

[0059] Generally, as the rover 102 is used to collect medical waste during surgical procedures and, in conjunction with the docking station 104, drained and cleaned, the rover 102 and / or docking station 104 may be configured to communicate operational data related to such activities to the server 284, such as via one or more computer networks 288. The server 282, which may generally form a processing system remote from the rover 102 and / or docking station 104 and may include one or more cloud servers and / or dedicated servers, may host one or more applications configured to aggregate operational data from different rovers 102 and track metrics to determine whether to trigger an action for the rover 102, such as displaying maintenance or usage notifications, as described below. The user terminals 284 may be configured to provide user access to the rover management and notification system 280A, or more specifically, applications hosted by the server 282, such as to view data specific to each rover 102, including operational data, status data, and tracked metrics associated with each rover 102, view aggregate operational data for the population as a whole, and receive notifications for maintaining the rovers 102. For example, without limitation, the user terminals 284 may include one or more personal computing devices generally remote from the rovers 102, such as a desktop, laptop, or thin client terminal. Mobile user devices 286, which may include temporary battery-powered personal computing devices such as laptops, tablets, or smartphones, may similarly function to access the rover management and notification system 280A, or more specifically, applications hosted by the server 282, as described herein. Additional details of the operation of the components of the rover management and notification system 280A are provided below.

[0060] The server 282, user terminal 284, and mobile device 286 may include controllers 128C, 128D, and 128E configured to implement the component functions, features, and processes described herein. Similar to the controllers 128A, 128B of the rover 102 and docking station 104 described above, each controller 128C, 128D, and 128E may include a processor, memory, and communications devices that may be configured at least similarly to those of the docking station controller 128B described above. The user terminal 284 and mobile device 286 may also include respective user interfaces 138B, 138C for presenting and receiving user input for adjusting data and notifications generated by the rover management and notification system 280A. For example, without limitation, each user interface 138B, 138C may include any one or more of the components of the user interface 138A described above in connection with each rover 102.

[0061] 3 illustrates an alternative example of a rover management and notification system 280B according to the present disclosure. As described above, in some implementations, the communication capabilities of the rover 102 may be relatively limited. For example, the communication capabilities of the rover 102 may be limited to relatively short-range and / or direct connection communication technologies, such as proximity-based wireless communication technologies (e.g., RFID, NFC), Bluetooth®, Wi-Fi® Direct, Zigbee®, or LOS-based wireless communication technologies (e.g., IR). To this end, the rover 102 may not be able to establish a data connection with the server 284 directly via the computer network 288. In this case, as illustrated in the example rover management and notification system 280B of FIG. 3 , one of the other components of the rover management and notification system 280B, such as the docking station 104 and / or the mobile device 286, may be configured to act as an edge communication device for the rover 102.

[0062] For example, as described above, each rover 102 may be configured to establish a data connection, or more specifically a wireless data connection, with the docking station 104 when coupled to the docking station 104 for draining and / or cleaning using a relatively short-range communication technology, such as IR. The docking station 104 may be configured with a relatively long-range communication technology, such as Ethernet, cellular, or Wi-Fi, to facilitate communication between the docked rover 102 and the server 282 via the computer network 288. Additionally or alternatively, each rover 102 may be configured to establish a wireless data connection with a nearby mobile device 286 using a relatively short-range communication technology, such as Bluetooth or Wi-Fi Direct. The mobile device 286 may be configured with a relatively long-range communication technology, such as Ethernet, cellular, or Wi-Fi, to facilitate communication between the rover 102 and the server 282 via the computer network 288.

[0063] During operation of the rover management and notification system 280A, 280B, operational data for a given rover 102 in the fleet indicating the rover's 102 updated operation, including cleaning cycle data and / or surgical procedure data, may be sent to the server 284 to be aggregated with similar data from other rovers 102, which can facilitate providing managers with a complete picture of the rover 102 fleet to plan future use and replacement of rover 102 components, thereby checking compliance with relevant policies (e.g., smoke evacuation policy, cleaning policy), and identifying return on investment for the rover 102 fleet. These tasks have previously not been possible, or have only been possible to a very limited extent, such as by comparing order history with current inventory, conducting post-mortem interviews of clinical users, and attempting to compare past and present red bag waste costs for a given department.

[0064] To this end, the rover management and notification system 280A, 280B may provide an application that allows administrators and other non-clinical users to view aggregate data regarding the above matters (e.g., replacement components, compliance, return on investment) in different contexts, such as by rover 102, by day, by week, by month, by department, or by type of rover 102. As an example, based on aggregate operational data generated from the operational data of individual rovers 102, the rover management and notification system 280A, 280B may provide a graphical user interface, such as on the user interface 138B, 138C of the remote terminal 284 and / or mobile device 286, that allows users to view graphs of filter usage in various contexts, including when smoke is present and when smoke is not present, graphs of surgical waste fluid waste volume in various contexts, and add factors such as canister or red bag waste cost per liter of waste fluid to determine return on investment.

[0065] As a further example, the aggregation functionality of the rover management and notification systems 280A, 280B may allow a user to view graphs of manifold usage in various contexts to plan future usage and orders. For example, during a given medical procedure involving the rover 102, the rover controller 128A of the rover 102 may be configured to generate manifold usage data by assigning a manifold usage profile to each use of the interchangeable manifold 124 inserted into the rover 102. The usage profile assigned to each use of the interchangeable manifold 124 may include one or more data (datums) selected from the group consisting of date of use, time of use, medical specialty, type of procedure, associated rover type and / or model and / or unique identifier, and manifold type and / or part number and / or unique identifier. Additionally or alternatively, the rover controller 128A may be configured to generate manifold usage data by identifying a fluid waste volume for each use via a fluid measurement system (e.g., rover sensor 166) associated with the manifold 124.

[0066] The rover controller 128A of each rover 102 may be configured to transmit manifold usage data, including manifold usage profiles and / or fluid waste volumes, to the server 284, which may be configured to generate and provide aggregate usage data for display, such as on the user interfaces 138B, 138C of the remote terminals 284 and / or mobile devices 286, illustrating manifold usage characteristics across a population of rovers 102. As an example, the server 284 may be configured to generate the aggregate data by, at least in part, determining fluid waste costs based on fluid waste volumes and a weight-based waste cost conversion, comparing the fluid waste costs to operating costs of the rover 102, and displaying the cost savings on the user terminal 284, such as in response to receiving a corresponding request from the user terminal 284. This analysis, enabled by the aggregation of operational data from multiple rovers 102, may assist a user in quickly and accurately identifying cost benefits of a population of rovers 102 managed by the rover management and notification systems 280A, 280B.

[0067] The aggregation capabilities of the rover management and notification systems 280A, 280B may also aid in diagnosing common issues with multiple rovers 102 across a fleet. For example, each rover controller 128A may be configured to generate error codes based on anomalies identified during the operation of the rover 102. Error code data indicative of such error codes may be transmitted from each rover 102 to the server 284, which may then generate aggregated error code data indicative of diagnostic patterns across the fleet of rovers 102. For example, without limitation, the transmitted error code data may include one or more data selected from the group consisting of date of use, duration of use, medical specialty, type of procedure, associated rover type and / or model and / or unique identifier, and part number. Transmission of such data to the server 284 may also enable a technician, such as via the user terminal 284, to view a report of rover history including error codes with time / date stamps prior to dispatching service, which may help improve diagnostic and corrective response efficiency, saving time and money and minimizing rover downtime.

[0068] The server 282 may be configured to use push communications to provide the aggregated data for display on one of the user interfaces 138 of other devices in the rover management and notification systems 280A, 280B, such as a user terminal 284, a mobile device 286, or a rover 102. Alternatively, the aggregated data may be pulled from the server 282 to a given one of the devices periodically and / or on-demand, such as based on user input received via the device's user interface 138. In some examples, in response to a given rover 102 being coupled to the docking station 104, and optionally in response to corresponding user input being received at the user interface 138A of the rover 102, the docking station 104 may be configured to request the aggregated data from the server 282 for display on the user interface 138A of the rover 102, such as via the docking station 104 operating as an edge device as described above.

[0069] In some implementations, a given mobile device 286 may be configured to act as a remote control for the rover 102, such as to trigger and control the operation of the rover 102 to collect medical waste during a surgical procedure, via a data connection established between the mobile device controller 128E and the rover controller 128A when they are in close proximity to each other. Additionally or alternatively, such a mobile device 286 may be configured to relay status information about the rover 102 during a surgical procedure, such as when the rover 102 is currently applying suction to a surgical site, and operational data of the rover 102 related to the surgical procedure as described herein.

[0070] In some implementations, the mobile device 286 may further include a camera 290 or other scanner in communication with the mobile device controller 128E, which may be configured to activate the camera 290 to scan the practitioner's ID badge before allowing the rover 102 to operate. To this end, the mobile device controller 128E may be configured to correlate the scanning of the ID badge with the start of a procedure and, in response, communicate a corresponding status update to the server 282 indicating that the rover 102 has entered a clinical state. The mobile device controller 128E may be configured to correlate a subsequent scanning of the badge with the end of a procedure and, in response, communicate a further status update to the server 282 indicating such, along with rover 102 operation data that occurs during the procedure. In some implementations, the mobile device controller 128E may be configured to restrict communication to and / or from the rover 102 when it is in a clinical state or applying suction, such as to avoid disruptions to the operation of the rover 102.

[0071] In some implementations, upon recognizing a given practitioner's badge, the mobile device controller 128E may be configured to set the operating parameters (e.g., suction level, maximum flow rate) of the rover 102 based on presets associated with the practitioner. Additionally, or alternatively, the mobile device controller 128E may be configured to display an interface for selecting a given type of treatment to be performed by the rover 102 and set the operating parameters of the rover 102 based on presets associated with the selected treatment type. Further in response to receiving the selected treatment type, the mobile device controller 128E may be configured to provide instructions for use of the rover 102 regarding the details of the treatment type.

[0072] As explained above, the operational data for a given rover 102 may include surgical procedure data indicative of the operational characteristics of the rover 102 during one or more surgical procedures, which may be used by the rover controller 128A of the given rover 102 and / or by the server 282 to determine whether to trigger an action (response) for the given rover 102. At least a portion of such operational data may be generated by the sensors 166 of the rover 102 and transmitted to the server 282 upon completion of each surgical procedure, such as via a connected mobile device 286 or when docked at the docking station 104. Additionally or alternatively, in some implementations, the mobile device 286 may be used to generate the operational data for the given rover 102, such as by being configured to image the waste canister 116 with the camera 190 during and / or after the procedure and / or analyze the images to identify characteristics of waste collection by the rover 102 in connection with the surgical procedure.

[0073] 4 , a given rover 102 may include a front casing 292 coupled to the vertical chassis 114, the front casing defining at least one cutout or window 294 for exposing a portion of the waste canister 116. The waste canister 116 may be formed from a transparent material through which a user may visually observe the waste material collected in the waste canister 116 and, if desired, visually estimate the volume of the waste material collected in the waste canister 116 by volumetric markings located on the exterior surface of the waste canister 116. The optical clarity of the waste canister 116 also allows the waste material collected in the waste canister 116 to be imaged by a camera 290 integrated into the mobile device 286. Images from the camera 290 may be transmitted to and processed by the controller 128E of the mobile device 286 to determine operational data of the rover 102 related to the surgical procedure, such as at least one of the degree of obstruction of the collected waste material, the composition of the collected waste material (e.g., blood concentration), and the period (duration) that the waste material resides in the waste canister 116. More specifically, optical properties of the waste material may be analyzed and processed to determine such data, as disclosed in commonly owned U.S. Patent No. 8,792,693, issued July 29, 2014, and International Application No. PCT / US2023 / 025603, filed June 16, 2023, the contents of each of which are incorporated herein by reference in their entirety.

[0074] At least one equipment cradle 296 may be removably coupled to or rigidly fixed to the rover 102. The equipment cradle 296 may position the camera 290 relative to the waste canister 116 in a precise manner (with high precision) to provide continuous image capture (e.g., a video feed) of at least substantially the entire waste canister 116. The video feed generates continuous data from which the above characteristics may be determined in real time, and this data may be used to dynamically adjust one or more corresponding notification thresholds, such as a cleaning notification threshold, for the rover 102, thereby facilitating its optimal performance, as described in more detail below.

[0075] 5 illustrates a method 300 for dynamically managing the use and maintenance of a fleet of rovers 102 based on an analysis of the operation of a plurality of rovers 102, which may extend the useful life of the rovers 102 and improve the operating efficiency of the fleet. The method 300 may be implemented by the rover management and notification system 280A, 280B, or more specifically, by one or more controllers 128 of the rover management and notification system 280A, 280B, and may be performed for each rover 102 in the fleet.

[0076] In block 302, the state of the rover 102 may be set to idle. Generally, when a rover 102 is made available to a healthcare professional to collect medical waste, the rover 102 may initially enter an idle state, which may correspond to the rover 102 being in an inoperative state, being powered down, being in a low-power or standby mode, the manifold 124 not being received in the receptacle 120 of the rover 102, and / or not being enabled to activate suction. The rover controller 128A and / or the server controller 128C may be configured to track the current state of each rover 102. Thus, in response to a user checking the status of a given rover 102, such as via a user terminal 284, a mobile device 286, or the user interface 138A of another rover 102, the rover controller 102 and / or the server controller 128C may provide status data indicating the current state of the rover 102 to the requesting device for display, such as via the computer network 288.

[0077] In block 304, a determination may be made whether the rover 102 has left the idle state and entered a different state, such as a docked state or a clinical state. The docked state may generally correspond to the rover 102 being successfully docked to the docking station 104. The determination of whether the rover 102 is in a docked state may be made by the rover 102, or more specifically the rover controller 128A of the rover 102, or by the docking station 104, or more specifically the docking station controller 128B of the rover docking station 104. In one example, successful docking may be determined using sensors integrated into the receptacle 228 or the strike plate 230. Alternatively, successful docking may be detected based on communication being established between the rover 102 and the docking station 104, such as via the communication devices 134A, 134B. For example, the docking station 104, or more specifically the docking station controller 128B, may be configured to determine that successful docking has occurred with a given rover 102 in response to receiving a communication from the rover controller 128A of the rover 102 via the IR transceiver 127, 229. Such a communication may identify the particular rover 102 coupled to the docking station 104, such as by providing a unique identifier for the rover 102. In response to the rover 102 successfully docking with the docking station 104, the rover controller 128A may be configured to display a notification on the user interface 138A of the rover 102 indicating the successful docking.

[0078] In response to determining that the rover 102 is in a docked state (the "Yes-Docked" branch of block 304), the status of the rover 102 may be set to a docked state in block 306, such as by the rover controller 128A and / or the server 284. For example, in response to the rover 102 being docked, a status update indicating the docked state of the rover 102 may be communicated to the server 284 from the rover 102 or the docking station 104, etc., via the computer network 288. Thus, in response to a user checking the status of a given rover 102, such as via a user terminal 284, a mobile device 286, or a user interface 138A of another rover 102 in communication with the server 284, the server 284 may provide status data indicating the docked state of the rover 102 to the requesting device for display. The status data may further indicate a particular docking station 104 for display, and may also indicate the location of the docking station 104 within the healthcare facility or system. Additionally or alternatively, the rover controller 128A may locally store the docked state of the rover 102 and may be configured to respond to requests from remote devices with status data indicating, for display, the docked state of the rover 102, the particular docking station 104, and / or the location of the docking station 104 within the healthcare facility or system.

[0079] In some implementations, in response to the rover 102 entering a docked state, the method 300 may proceed to block 308A, where operational data of the rover 102 is processed. As previously described, the server controller 128C may be configured to track one or more metrics associated with each rover 102 to determine whether notifications related to the rover 102 should be triggered based on the operational data of the rover 102. As previously described, the rover 102 may have relatively limited communication capabilities, which may prevent the rover 102 from communicating directly with the computer network 288, such as to exchange operational data with the server 284. In some examples, the rover 102 may be configured to pair with the mobile device 286, which may therefore function as an edge device to receive operational data from the rover 102 for transmission to the server 282 via the computer network 288, such as upon completion of a procedure, and / or to receive data (e.g., notification data, software updates) from the server 282 via the computer network 288 for transmission to the rover 102. However, if the rover control device 128A has operational data that has not yet been uploaded to the server 282, such as because the mobile device 286 is not available to pair with the rover 102 or the rover 102 is not configured to cooperate with the mobile device 286 to access the computer network 288, the method 300 may proceed to block 308A in response to the rover 102 being docked. Exemplary details of block 308A are described below with reference to FIG. 7 .

[0080] In block 310A, a determination may be made, such as by the rover controller 128A and / or server controller 128C of the rover 102, whether a notification should be displayed on the rover 102. For example, in response to receiving a status update indicating the docked status of the rover 102, the server controller 128C may be configured to look up and / or generate notification data for the rover 102, which may indicate whether a notification has been triggered for the rover 102. More specifically, the notification data may indicate any outstanding (unprocessed) notifications for the rover 102 that may have been previously triggered, as described in more detail below. The notification data may indicate the type of notification being triggered, such as a maintenance-related notification (e.g., cleaning, filter) or a usage-related notification. The server controller 128C may be configured to transmit such notification data to the rover 102 or the docking station 104 via one or more computer networks 288, and the docking station 104 may be configured to transmit a corresponding communication to the rover controller 128A via a data connection formed therebetween, which communication causes the rover controller 128A to determine whether a notification should be displayed. Alternatively, the determination of block 306 may be made by the rover controller 128A of the rover 102 based on notification data previously generated by the rover controller 128A and / or locally stored notification data, as will be described in more detail below.

[0081] In response to determining that a notification should be displayed on the rover 102 (the "Yes" branch of block 310A), one or more notifications may be generated, such as by the rover controller 128A, and displayed on the user interface 138A of the rover 102 in block 312A. The content of the displayed notification may depend on the type of outstanding notification indicated by the notification data. For example, a cleaning-related notification may be configured to instruct a user to run a particular type of cleaning cycle on the rover 102, such as an extended cleaning cycle. This may instruct the user to run a particular type of cleaning cycle when docking the rover 102 to the docking station 104 and before running another type of cleaning cycle. A usage-related notification may instruct the user to use another, less frequently used rover in the fleet of rovers 102 for the next medical waste collection procedure, such as to provide balanced usage of the fleet as a whole. The filter-related notification may instruct the user to change a filter on the rover 102, such as the aerosol filter 160 and / or the particulate filter 164 described above.

[0082] In response to generating one or more notifications (block 312A), or in response to determining that no notifications should be generated (the "No" branch at block 310A), a cleaning cycle and / or a drain cycle may be performed on the rover 102 in block 314. As an example, a user may select and initiate a drain cycle and / or a cleaning cycle via the user interface 138A of the rover 102, which may subsequently cause the rover controller 128A to communicate instructions to the docking station controller 128B to begin execution of the drain cycle and / or the selected cleaning cycle. The docking station 104 may then perform the drain cycle and / or the cleaning cycle on the rover as described above.

[0083] In block 308B, in response to the waste canister 116 being emptied and / or cleaned by the docking station 104 according to the selected cleaning cycle, operational data for the rover 102 may be processed, such as based on characteristics of the cleaning cycle. The rover management and notification systems 280A, 280B may maintain operational data specific to each rover 102 across various operational aspects of the rover 102. The operational data for each rover 102 may be maintained locally by the rover 102, such as in memory 132A of the rover 102. Additionally, or alternatively, the operational data for each rover 102 may be maintained centrally at the server 284, such as in memory 132C. By way of example and without limitation, the operational data stored for each rover 102 may include cleaning cycle data for the rover 102 and / or surgical procedure data for the rover 102. The cleaning cycle data may generally indicate information related to drain and / or cleaning cycles performed on the rover 102 by the docking station 104, such as indicated by data generated by the sensors 166, 234 during such cycles. The surgical procedure data for the rover 102 may indicate information related to the use of the rover 102 to collect medical waste during a surgical procedure, such as error code data, fluid collection volume data, filter usage data, vacuum pump runtime data, manifold usage data, procedure type data, patient data, and / or visual data determined by imaging the waste canister 116 as described above. In some examples, the rover management and notification systems 280A, 280B may maintain management data for each rover 102, such as return on investment data and / or service data for the rover 102.

[0084] In general, processing the operational data for a rover 102 in block 308B may include analyzing operational data specific to that rover 102 to determine whether to trigger a maintenance notification, such as a cleaning-related or filter-related notification, for the given rover 102. The operational data for a given rover 102 may also be combined in block 308B with operational data for other rovers 102 in the fleet to also determine whether to trigger notifications, such as usage-related notifications, to provide a comprehensive understanding of the fleet as a whole and to facilitate efficient allocation of rovers 102. Additional details of block 308B are described in more detail below with reference to FIG.

[0085] In response to the operation data for the rover 102 being processed in block 308B, the method 300 may return to block 302 to set the state of the rover 102 back to idle. For example, assuming the rover 102 is currently in a docked state, the rover 102 may be undocked from the docking station 104. In response to the rover 102 becoming undocked, the rover controller 128A or the docking station controller 128B may be configured to communicate a status update to the server 284 indicating that the rover 102 is no longer docked to the docking station 104 and has returned to an idle state. The server controller 128C may be configured to store such status as part of the operation data specific to the rover 102. Additionally or alternatively, the rover controller 128A may be configured to reflect the idle state of the rover 102 in the operation data stored locally on the rover 102.

[0086] As described above in connection with block 304, the rover 102 may exit the idle state by being placed in clinical use, such as in preparation for a surgical procedure. This determination may be made by the rover 102, or more specifically by the rover controller 128A of the rover 102. As non-limiting examples, the rover controller 128A may be configured to determine that the rover 102 has entered clinical use in response to the rover 102 being powered on while not docked to the docking station 104, in response to the rover 102 receiving user input via the user interface 138A indicating waking up from a low-power or standby mode, or in response to one or more manifolds 124 being installed on the rover 102. Additionally or alternatively, this determination may be made by the controller 128E of the mobile device 286 connected to the rover 102 in response to receiving user input indicating that the rover 102 will be used in a surgical procedure and / or in response to scanning an ID badge associated with a practitioner, etc.

[0087] In response to determining that the rover 102 is in clinical use (the "Yes-Clinical" branch of block 304), the status of the rover 102 may be set to a clinical state, such as by the rover controller 128A and / or the server controller 128C, in block 316. For example, a status update indicating the clinical status of the rover 102 may be communicated to the server 284 from the rover 102 or a mobile device 286 connected to the rover 102. Thus, in response to a user checking the status of a given rover 102, such as via a user terminal 284, a mobile device 286, or the user interface 138A of another rover 102 in communication with the server 284, the server 284 may provide status data indicating the clinical status of the rover 102 to the requesting device for display. The status data may further indicate the location of the rover 102 within the healthcare facility or system. Additionally or alternatively, the rover control device 128A may locally store status data indicating the clinical status of the rover 102 and may be configured to respond to requests from remote devices with status data indicating the clinical status of the rover 102 and / or the location of the rover 102 within the healthcare facility or system for display.

[0088] In block 310B, a determination may be made, such as by the rover controller 128A and / or the server controller 128C of the rover 102, whether a notification should be displayed on the rover 102. Block 310B may include processes similar to those of block 310A described above. For example, in response to receiving a status update indicating the clinical status of the rover 102, the server controller 128C may be configured to examine and / or generate notification data for the rover 102, which may indicate whether a notification has been previously triggered for the rover 102. More specifically, the notification data may indicate any outstanding notifications for the rover 102 that may have been previously triggered, as described in more detail below. The notification data may indicate the type of notification being triggered, such as a cleaning-related notification, a usage-related notification, or a filter-related notification. The server controller 128C may be configured to transmit such notification data to the rover 102 via one or more computer networks 288, and the rover 102 may be configured to determine whether to display a notification based on the received data. Alternatively, the determination of block 310B may be made by the rover controller 128A of the rover 102 based on notification data previously generated by and / or locally stored by the rover controller 128A, as will be described in more detail below.

[0089] In response to determining that a notification should be displayed on the rover 102 (the "Yes" branch of block 310B), in block 312B, one or more notifications may be generated, such as by the rover controller 128A, and displayed on the user interface 138A of the rover 102. Block 312B may include processes similar to those of block 312A described above.

[0090] In response to generating one or more notifications (block 312B) or in response to determining that a notification should not be generated (the "NO" branch of block 31B), the operation of the rover 102 may be tracked in block 318. The operation of the rover 102 tracked in block 310B may generally correspond to at least a portion of the operational data maintained for each rover 102 as described herein. More specifically, the rover 102, or more specifically the rover controller 128A of the rover 102, may be configured to track operational data, or more specifically surgical data, of the rover 102 as the rover 102 is used and / or maintained, such as based on data generated by the sensors 166 of the rover 102 and / or visual data generated using the mobile device 286 as described above. Such data may be used to update one or more metrics tracked for the rover 102 to determine whether to trigger an action (response) for the rover 102, such as a notification.

[0091] As an example, tracking rover 102 operation in block 318 may include tracking use of the rover 102's vacuum source (e.g., vacuum pump 118) to aspirate medical waste to generate vacuum runtime data for the rover 102. For example, in response to each instance in which the rover 102's vacuum source is activated to draw medical waste into at least one of the waste canisters 116, the rover controller 128A may be configured to index (change) a counter or start a timer, such as until the vacuum source stops drawing medical waste into the canisters 116. In some implementations, the rover controller 128A may be configured to determine when medical waste is being drawn into the canisters 116 based on when the rover controller 128A is activating the rover 102's vacuum pump 118 and / or based on data from one or more sensors 166 associated with each of the waste canisters 116, such as weight sensors or volume sensors.

[0092] Additionally or alternatively, tracking rover 102 operation in block 324 may include tracking filter usage of the rover 102 to generate filter usage data for the rover 102. For example, the rover controller 128A may be configured to index a counter or start a timer specific to the aerosol filter 160 of the rover 102 in response to each instance of the rover 102 being operated in which the aerosol sensor 162 indicates that one or more aerosols are present or present above a preset non-zero threshold and / or the aerosol sensor 162 indicates that aerosols are not present or not above a preset threshold, such as until a vacuum source such as the blower 158 of the aerosol removal system 150 draws fluid through the filter 160 and / or the blower 158 stops drawing fluid through the filter 160. Similarly, the rover controller 128A may be configured to index a counter or start a timer specific to the particulate filter 164 in response to each instance of the rover 102 being activated in which a vacuum source, such as the vacuum pump 118, draws fluid into the waste canister 116, such as until the vacuum pump 118 stops drawing fluid through the particulate filter 164.

[0093] In some examples, tracking filter usage of the rover 102 may also include assigning a filter usage profile to each use of each filter 160, 164 during a medical procedure. Each assigned filter usage profile may include one or more data selected from the group consisting of date of use, time of use, medical specialty, type of procedure, associated rover type, model, and / or unique identifier, and filter type, model, and / or unique identifier.

[0094] Additionally or alternatively, tracking filter usage may include determining whether a filter change event has occurred. As an example, each filter 160, 164 for use with the rover 102 may include or be associated with an RFID tag that indicates whether the filter 160, 164 is new or used. The rover controller 128A may be configured to read this data from the RFID tag of each currently installed filter 160, 164 to determine whether the filter 160, 164 is new or used. In response to read data indicating that a given filter 160, 164 is new, the rover controller 128A may be configured to determine that a filter replacement event has occurred and update the status of the used filter 160, 164, such as by locally recording the unique identifier of the filter 160, 164 present on the RFID tag and / or writing data to the RFID tag indicating that the filter 160, 164 is currently in use.

[0095] Additionally or alternatively, tracking rover 102 operation in block 308 may include tracking manifold usage to identify manifold usage data for the rover 102. For example, the rover controller 128A may be configured to assign a manifold usage profile to each use of the replaceable manifold 124 during a medical procedure. The usage profile assigned to each use of the replaceable manifold 124 may include one or more data selected from the group consisting of date of use, time of use, medical specialty, type of procedure, associated rover type, model, and / or unique identifier, and manifold type, model, and / or unique identifier.

[0096] Additionally or alternatively, tracking rover 102 movement in block 318 may include tracking fluid waste volume to generate fluid waste volume data for the rover 102. For example, the rover controller 128A may be configured to track fluid waste volume for the rover 102 based on data generated by sensors 166 of the rover 102.

[0097] Additionally or alternatively, tracking the rover 102 operation in block 318 may include tracking error codes generated by the rover 102 to generate error code data for the rover 102. For example, the rover controller 128A may be configured to generate error codes based on anomalies identified during operation of the rover 102, such as based on data generated by the sensors 166.

[0098] Following block 318, the method 300 may move to block 308B, where operational data for the rover 102 may be processed, such as based on the rover 102 movement tracked in block 324. As previously mentioned, processing the operational data for the rover 102 in block 314 may include analyzing one or more metrics corresponding to operational data specific to a given rover 102 to determine whether to trigger notifications and to provide a comprehensive understanding of the population as a whole. Additional details of block 308B are described in more detail below with reference to FIG. 7.

[0099] In response to the operational data for the rover 102 being processed in block 308B, the method 300 may return to block 302 to set the state of the rover 102 back to an idle state, as described above. For example, assuming the rover 102 is currently in a clinical state, the rover 102 may be powered down or placed in a low power or standby state, all manifolds 124 may be removed from the rover 102, and / or an input indicating the end of treatment may be provided to the mobile device 286 connected to the rover 102.

[0100] While the rover 102 is in the idle state, the rover management and notification system 280A, 280B may be configured to periodically process the rover 102 operation data to determine, by way of example, whether a notification should be triggered. Thus, continuing again with block 304, in response to determining that the rover 102 has not left the idle state (the "No" branch of block 304), an idle metric may be tracked in block 322. For example, an idle counter may be indexed or an idle timer may be started (if not already started), such as by the rover controller 128A or the server controller 128C. In block 324, a determination may be made whether the idle metric has reached a preset value corresponding to a desired wait time. If so (the "Yes" branch of block 324), the method 300 may proceed to block 308C, where the rover 102 operation data may be processed. Block 308C may generally correspond to blocks 308A and 308B, as described below. Thereafter, in block 326, the idle metric may be reset.

[0101] In the examples described above, the rover 102 is shown entering the idle state from a clinical state and a docked state, however, as will be appreciated by those skilled in the art, in other implementations the rover 102 may transition from a docked state to a clinical state or vice versa without necessarily entering the idle state.

[0102] 6A and 6B show GUI screens that may be generated on the user interface 138A of the rover 102 when the rover 102 enters a docked state, such as when block 310A indicates that a filter-related notification should be triggered on the rover 102. In response to the rover 102 being docked, the GUI may present a screen 332 including various types of selectable cleaning cycles along with a filter notification metric indicating the remaining life of the filter 160. In response to selecting a given type of cleaning cycle, in this case a "normal wash" cleaning cycle, the GUI may proceed to screen 334, where a selectable element is provided to the user for initiating execution of the selected cleaning cycle. In response to initiating execution of the selected cleaning cycle, the GUI may present a further screen 336 including a status bar indicating the progress of the cleaning cycle. Screen 336 may also provide one or more notifications specified for the rover 102, in this case a filter-related notification instructing the user to replace the filter 160 and then reset the filter notification metric. Selection of the replace and reset filter 160 element may cause the GUI to advance to screen 338 to show a reset filter notification metric and also to show a cleaning cycle status bar. Upon completion of the cleaning cycle, the GUI may then advance to screen 340 to indicate that the cleaning cycle is complete and also to provide a selectable element for releasing the rover 102 from the docking station 104. Finally, selection of the release element may cause the GUI to present screen 342, which provides an indication that the rover 102 is ready to be removed from the docking station 104.

[0103] 7 shows a method 350 for processing operational data of rovers 102, such as to determine if notifications should be triggered and / or to provide a comprehensive understanding of the population as a whole. Method 350 may be performed in blocks 308A, 308B and / or 308C of method 300 shown in FIG. 5 and may be implemented by rover management and notification systems 280A, 280B, or more specifically, one or more controllers 128 of rover management and notification systems 280A, 280B.

[0104] In block 352, operational data specific to the rover 102 may be updated, such as by the rover controller 128A and / or the server controller 128C, based on, for example, cleaning and other operations of the rover 102 as described above. As previously described, the rover management and notification systems 280A, 280B may maintain operational data specific to each rover 102, which operational data spans various operational aspects of the rover 102 and provides a comprehensive snapshot of the rover 102 to enable efficient utilization and maintenance of the rover 102 and the fleet as a whole. The operational data for each rover 102 may be maintained locally by the rover 102, such as in memory 132A of the rover 102. Additionally or alternatively, the operational data for each rover 102 may be maintained centrally at the server 284, such as in memory 132C of the server 284. In this case, updating the operational data specific to the rover 102 in block 352 may include transmitting locally recorded operational data over the network 288 to the server 284, such as from the rover 102, and / or via the docking station 104 to which the rover 102 is docked, and / or via the mobile device 286 to which the rover 102 is paired. The locally recorded operational data may generally include data related to the operation of the rover 102 that has not yet been transmitted to the server. For example, without limitation, the transmitted data may include one or more of cleaning cycle data for the rover 102, error code data for the rover 102, filter data for the rover 102, vacuum pump runtime data for the rover 102, manifold usage data for the rover 102, and / or vision data for the rover 102.

[0105] More specifically, without limitation, data that may be provided in the operational data for a given rover 102 includes the rover part number, the rover serial number, the total number of rover power-on events including main power-up and docking power-up, the total rover power-on time, the total number of vacuum pump start events, the total rover vacuum pump on time, the average vacuum pump current for all time, the average vacuum pump current before each of the last three cleaning cycles, the total number of smoke motor start events, the total smoke motor on time, the total ULPA filter usage, the total HEPA filter usage, the last time the HEPA filter life was reset, the last time the ULPA filter life was reset, the total number of times the HEPA filter life was reset, the total number of times the ULPA filter life was reset, the total number of short wash cleaning cycles completed, the total number of short wash cleaning cycles attempted, the last time a short wash cycle was completed, and the total number of normal wash cleaning cycles completed.Total number of normal wash cycles attempted, last time a normal wash cycle was completed, total number of long wash cleaning cycles completed, total number of long wash cleaning cycles attempted, last time a long wash cycle was completed, maximum cleaning cycle flow rate occurred on the rover, sum of all cleaning cycle flow rates occurred on the rover, minimum cleaning cycle flow rate occurred on the rover, total number of successful docking cycle flow rate calculations by the rover, maximum peak cleaning cycle water temperature occurred on the rover, sum of maximum peak cleaning cycle water temperatures occurred on the rover, minimum peak cleaning cycle water temperature occurred on the rover, sum of minimum peak cleaning cycle water temperatures occurred on the rover, total number of successful cleaning cycle water temperature calculations by the rover, most recent cleaning cycle flow rate occurred on the rover, most recent peak cleaning cycle water temperature occurred on the rover, total waste fluid collected and offloaded by the rover, total manifolds used by each canister 116 on the rover 102 may include the number of tank dumps attempted, the date of data download, the total number of tank dumps completed, the total number of volume resets, the total number of times the rover's IV pole up button was pressed, the date / timestamp of the last time the rover updated this data, the total number of 1-port manifolds used on this rover, the total number of 4-port manifolds used on this rover, the total number of 4-port SC manifolds used on this rover, the total number of manifolds used on this rover today, the total number of manifolds used on this rover yesterday, the total number of manifolds used on this rover 2 days ago, the total number of manifolds used on this rover 3 days ago, the total number of manifolds used on this rover 89 days ago, the latest error code (left of the decimal point), the latest error date / timestamp (UTC), the second most recent error code (left of the decimal point), the second most recent error date / timestamp (UTC), the 200th most recent error code (left of the decimal point), the 200th most recent error date / timestamp (UTC).

[0106] Additionally, or alternatively, the operational data updated in block 352 may include notification metrics used to determine whether notifications are appropriate for the rover 102. Correspondingly, updating the operational data specific to the rover 102 in block 352 may include updating one or more of these metrics, such as by the rover controller 128A and / or the server controller 128C.

[0107] As an example, the operational data maintained for each rover 102 may include one or more cleaning-related metrics specific to the rover 102. For example, the cleaning-related metrics may include metrics corresponding to the time since the last cleaning cycle, or since the first application of suction by the rover 102 since the last cleaning cycle. Additionally or alternatively, the cleaning-related metrics may include counters and / or timers tracking usage of the rover 102 since the last cleaning cycle, or since the first application of suction by the rover 102 since the last cleaning cycle, which is similar to the vacuum pump runtime data described above and may be indexed or initiated by the rover controller 128A, etc., in response to each instance the rover 102 is operated to collect medical waste.

[0108] In response to the completion of a cleaning cycle for a rover 102, cleaning-related metrics may be reset to zero in block 352. Assuming such metrics are maintained by the server 284 in response to the completion of a cleaning cycle for a given rover 102, the rover 102, or the docking station 104 to which the rover 102 is docked, or the mobile device 286 to which the rover 102 is paired, may be configured to send an indication of the completion of the cleaning cycle to the server 284 via the computer network 288, which may cause the server controller 128C to reset the cleaning-related metrics for the rover 102. In some implementations, at least one of the cleaning-related metrics maintained for each rover 102 may be specific to the execution of a particular type of cleaning cycle, such as a long wash cleaning cycle. Such cleaning-related metrics may be reset in response to the rover 102 undergoing a long wash cleaning cycle but not other cleaning cycle options.

[0109] A further cleaning-related metric that may be updated in block 352 is a cleaning cycle ratio specific to the rover 102. The cleaning cycle ratio may be the ratio of the number of times the rover 102 undergoes a cleaning cycle according to one or more cleaning cycle options (e.g., a short wash cleaning cycle and / or a standard wash cleaning cycle) to the number of times the rover 102 undergoes a cleaning cycle according to a long wash cleaning cycle option.

[0110] Further, as described above, updating the operational data specific to the rover 102 in block 352 may include updating one or more filter-related metrics specific to the rover 102, which may include one or more filter metrics indicative of the time since each filter 160, 164 was last replaced, the time since suction was first provided by the rover 102 since the particulate filter 164 was replaced, and / or the time since the aerosol removal unit 150 was first activated since the aerosol filter 164 was last replaced. Additionally or alternatively, the filter-related metrics may include at least one counter and / or timer that tracks usage of each filter 160, 164, such as based on data generated by the sensor 162 (e.g., for filter 160) of the aerosol removal unit 150 and / or the vacuum runtime data (e.g., for filter 164) described above. In response to identifying a filter replacement event, such as an aerosol filter 160 or a particulate filter 164, updating operational data specific to the rover 102 may include resetting filter metrics associated with the replaced filter 160, 164 to zero.

[0111] In response to updating the rover-specific data at block 352, the method 350 may proceed to block 354, where aggregated rover data may be updated. More specifically, the rover-specific operation data may be combined with operation data from other rovers 102 to form aggregated rover operation data. Generally, the aggregated rover operation data may provide information about each of the rovers 102 in relation to the population as a whole to enable smart decisions regarding the allocation and servicing of various rovers 102 to different surgical procedures. The aggregated rover operation data may also include one or more metrics for determining whether notifications are appropriate in relation to the population, as described in more detail below. In some implementations, the aggregated rover operation data may be updated by the server controller 128C.

[0112] For example, updating the aggregated rover operation data in block 354 may include determining relative cleaning data indicative of one or more relative cleaning-related metrics specific to a population of rovers 102, such as based on the updated rover cleaning cycle data for the given rover 102 (and that of the other rovers 102 on which method 300 is performed). More specifically, server 284 may be configured to aggregate the cleaning cycle data of each rover 102 in the population to generate one or more relative cleaning-related metrics for the population, such as a ranked list of the relative cleanliness of the population of rovers 102. For example, the ranked list of relative cleanliness may be based on the values ​​of the cleaning-related metrics tracked for each of the rovers 102 in the population, as described above.

[0113] Additionally, or alternatively, updating the aggregate rover operation data in block 354 may include determining relative usage data for a population of rovers 102. Unlike rover-specific usage data, such as that indicated by the vacuum pump runtime data described above, which may include data specific to one rover 102 in the population, relative usage data may include metrics indicative of the relative usage of two or more rovers 102. Such data may therefore enable efficient utilization of the population across multiple locations to maximize resources, such as to avoid one rover 102 in the population being used for the majority of procedures while another rover 102 is sparsely used.

[0114] Relative usage data may generally be generated by comparing rover usage data specific to one rover 102 with rover usage data specific to other rovers 102 in the population, with this comparison indicating the relative usage of the rovers 102. For example, the server controller 128C may be configured to determine a relative usage metric for a given pair of rovers 102 by subtracting the operation duration indicated by the received rover usage data, as indicated by the vacuum pump runtime data counter or timer described above, associated with one rover 102 of the given pair of rovers 102 from the operation duration indicated by the received rover usage data associated with the other rover 102 of the pair, with the magnitude of the difference being utilized as the relative usage metric for the pair of rovers 102. Additionally or alternatively, the server controller 128C may be configured to determine a relative usage metric for a given pair of rovers 102 by determining a usage ratio for the rovers 102, which may be a ratio of an operation duration indicated by rover usage data for one rover 102 of the given pair of rovers 102 to an operation duration indicated by usage data for the other rover 102 of the given pair of rovers 102. In some implementations, the server controller 128C may be configured to generate a given relative usage metric for each possible combination of two or more rovers 102 of the population. As a further example, the relative rover usage data may include a ranked list of relative usages of the rovers 102, which may be generated, at least in part, according to the relative usage metric described above.

[0115] In block 358, the aggregated rover operational data may be distributed to one or more devices of the rover management and notification systems 280A, 280B for selective display on those devices, such as each of the rovers 102, user terminals 284, and / or mobile devices 286. An exemplary GUI for showing such data on a given one of the above devices is described in more detail below.

[0116] In block 360, the rover-specific operational data and / or aggregated rover data, or more specifically the metrics indicated by such data, may be compared to one or more corresponding notification thresholds to determine whether to trigger any notifications. The rover-specific operational data may be compared by the controller 128A or the server controller 128C of a given rover 102, while the relative rover operational data may be compared by the server controller 128C. In some implementations, a user may be able to customize the thresholds, such as by interacting with the user interface 138 of the rover management and notification system 280A, 280B.

[0117] For example, comparing the rover-specific operational data in block 358 may include comparing the cleaning-related data for the given rover 102 to a corresponding preset threshold. More specifically, the rover controller 128A and / or the server controller 128C may be configured to compare each cleaning-related metric to a corresponding threshold. Additionally, or alternatively, comparing the rover-specific operational data in block 358 may include comparing the filter usage data for the given rover 102 to one or more preset thresholds. More specifically, the rover controller 128A or the server controller 128C may be configured to compare each filter usage metric to a corresponding threshold.

[0118] Additionally or alternatively, comparing the aggregated rover data in block 358 may include comparing the relative rover usage data to one or more corresponding thresholds. For example, server controller 128C may be configured to compare the magnitude of each difference described above to a threshold difference and / or to compare each relative usage ratio to a threshold usage ratio. As one non-limiting example, the threshold usage ratio may be at least 150%.

[0119] In some implementations, the rover controller 128A or the server controller 128C may be configured to dynamically update a given notification threshold for the rover 102 based on operational data for the rover 102. As an example, to facilitate optimal functioning of the rover 102, when a cleaning cycle, or a particular type of cleaning cycle (e.g., an extended wash cleaning cycle), should be performed on a given rover 102 may depend on the use of the rover 102 as indicated by the operational data. For example, the greater the blood concentration, retention time, and / or occlusion level of waste collected by the rover 102 as indicated by the visual data, the sooner it may be desirable to perform a cleaning cycle, or more specifically, an extended cleaning cycle, on the rover 102. Furthermore, the lower the water pressure and / or water temperature of the cleaning fluid provided by the facility when cleaning a given rover 102, the more frequently it may be desirable to perform a cleaning cycle, or more specifically, an extended cleaning cycle, on the rover 102. The type of treatment and / or patient condition (disease) may also be factors in how frequently a cleaning cycle, such as an extended cleaning cycle, should be performed. For example, if the patient for whom the rover 102 is being used has a high viral illness, it may be desirable to run a cleaning cycle, or more specifically, an extended wash cleaning cycle, on the rover 102 sooner than would otherwise be the case. The rover controller 128A or server controller 128C may be configured to take into account such information indicated by the operational data for the rover 102 to adjust (e.g., reduce) cleaning-related notification thresholds accordingly.

[0120] As another example, the useful life of each filter 160, 164 may vary with respect to the expected life and the composition of the fluid to which the filter 160, 164 is exposed, which may be indicated by operational data of the rover 102, such as in data generated by the aerosol sensor 162, and visual data indicative of the characteristics of the collected medical waste, respectively. Accordingly, the rover controller 128A or the server controller 128C may be configured to adjust the filter notification thresholds for each filter metric of a given rover 102 based on the expected life of the corresponding filter 160, 164 and such operational data.

[0121] At block 360, a determination may be made based on the comparison as to whether to trigger a notification. Such a determination may be made by the device performing the comparison (e.g., the rover controller 128A, the server controller 128C). In one implementation, a determination that a notification should be triggered may be made in response to one of the above comparisons indicating the metric being compared (e.g., a cleaning-related metric, a filter usage metric, a relative usage metric) being greater than its corresponding preset threshold.

[0122] In general, determining that a notification should be triggered in block 360 may function to dynamically update a usage or maintenance schedule for the rover 102 or a fleet of rovers 102 and generate an associated notification therefor. For example, the rover controller 128A and / or the server controller 128C may be configured to determine whether a cleaning schedule for a rover 102 should be dynamically updated and whether an associated notification should be generated based on a comparison of cleaning-related data for the rover 102. Similarly, the rover controller 128A and / or the server controller 128C may be configured to determine whether a filter maintenance schedule for a given rover 102 should be dynamically updated and whether an associated notification should be generated based on a comparison of filter usage data for the rover 102. Similarly, the server controller 128C may be configured to determine whether a usage schedule for a fleet of rovers 102 should be dynamically updated and whether an associated notification should be generated based on a comparison of relative usage data.

[0123] In response to determining that a notification should be triggered (the "Yes" branch of block 360), one or more notification operations (notification activations) may be performed, such as by the server controller 128C and / or the rover controller 128A, in block 362. In some implementations, such as when the server controller 128C determines that a notification should be triggered, notification data corresponding to a comparison indicative of a notification being triggered may be generated in the server controller 128C for a given rover 102. Thus, in response to the rover 102 later communicating with the server 284, such as in one or more of blocks 308A, 308B, and 308C described above, the notification data may be forwarded to the rover 102, causing the rover 102 to display a notification corresponding to the notification data.

[0124] Additionally or alternatively, performing one or more notification operations in block 362 may include generating and displaying a real-time notification regarding the determination that a notification is triggered, such as on the user interface 138A of the given rover 102, and / or the user interface 138B of the user terminal 284, and / or the user interface 138C of the mobile device 286 registered to the given rover 102. For example, the given rover 102 and / or the server 284 may be configured to generate and push such notifications to one or more of the above devices based on stored contact data indicating devices subscribed to the given rover 102 and their contact information (e.g., phone number, IP address, email address) associated with the given rover 102. In this way, notifications can be provided to the people best suited to receive such notifications. For example, when the filter 160 or particle filter 164 of the aerosol removal system 150 is due for replacement, the rover 102 can be configured to notify the clinical user by locally prompting the clinical user to replace it immediately. However, the clinical user is often not the same person who actually purchases and replaces the filter. Thus, in addition to, or rather than displaying a filter-related notification on the rover 102, the server controller 128C may cause the notification to be displayed on the user terminal 284 or mobile device 286 of the person best suited to receive such a notification.

[0125] As previously described, the content of the notification may depend on the notification type, which itself may depend on the comparison that implied the notification-triggering event. For example, each comparison of relative usage data may involve rover usage data specific to at least two rovers 102. In response to a comparison of such data indicating that a notification should be triggered, the notification generated from this comparison may instruct the user to use a less frequently used rover 102 of the rovers 102 implied by the comparison, such as indicated by rover usage data specific to the rover 102 implied by the comparison. As an example, for a given group of rovers 102 implied by a comparison resulting in such a notification, the server control device 128C may be configured to generate notification data for each rover 102 whose relative rover usage data indicates more frequent use than less frequently used rovers 102, so that when a given one of the more frequently used rovers 102 is docked or enters a clinical state, a notification is provided on the user interface 138A of the rover 102 instructing the user to use a less frequently used rover 102 of that group.

[0126] As a further example, performing a notification operation in block 362 in response to filter usage data for a given rover 102 resulting in a determination of a notification trigger event may include triggering a notification at any user terminal 284 subscribed to the rover 102, such as the user terminal 284 of an administrator responsible for ordering and replacing rover filters 160, 164.

[0127] As previously described, the rover management and notification systems 280A, 280B may provide applications that allow administrators and other non-clinical users to obtain a complete view of the fleet of rovers 102 for planning for future use and replacement of rover 102 components, thereby checking compliance with relevant policies (e.g., smoke evacuation policies), and identifying the return on investment of the fleet of rovers 102. FIG. 8 shows a GUI home screen 702 that may be generated on the user interface 138A of the rover 102 and / or the user interface 138B of the user terminal 284 and / or the user interface 138C of the mobile device 286, such as in accordance with the exemplary methods described above. As shown in the illustrated example, the home screen 702 may include a rover summary portion 704 and a docking station summary portion 706, each of which provides various data about the stock of corresponding equipment deployed by the healthcare facility or system.

[0128] The rover summary portion 704 may include at least one data indicating the number of rovers 102 deployed by a given healthcare facility or system. In some examples, a healthcare facility or system may utilize various types of rovers. For example, a given healthcare facility or system may use one or more Type A rovers 102 and one or more Type B rovers 102. Relative to the Type A rovers 102, the Type B rovers 102 may have different characteristics, such as being smaller and more portable but capable of holding less waste. In this case, the rover summary portion 704 may include rover Type A rover data 708A indicating the number of Type A rovers 102 owned by the healthcare facility or system, and may include Type B rover data 708B indicating the number of Type B rovers 102 owned by the healthcare facility or system.

[0129] For each rover data 708A, 708B, the rover summary portion 704 may also indicate the status of the stock of a given type of rover 102. By way of example, for each rover data 708A, 708B, the rover summary portion 704 may include action data 710A, 710B indicating the number of rovers 102 of the given type that currently require action (e.g., maintenance), future action data 712A, 712B indicating the number of rovers 102 of the given type that immediately require action, action requested data 714A, 714B indicating the number of rovers 102 of the given type for which action has already been requested, and unavailability data 716A, 716B indicating the number of rovers 102 of the given type that are not currently available for use (e.g., non-functional).

[0130] Similarly, the docking station summary portion 706 may include docking station data 708C indicating the number of docking stations 104 owned by the healthcare facility or system, support data 710C indicating the number of docking stations 104 currently requiring attention (e.g., maintenance), future support data 712C indicating the number of docking stations 104 requiring immediate attention, support request data 714C indicating the number of docking stations 104 for which support has already been requested, and unavailability data 716C indicating the number of docking stations 104 that are not currently available for use (e.g., non-functioning).

[0131] 9 illustrates another screen 739 that may be generated by the GUI, such as in response to a user selection of the list view option 736 on screen 730 (FIG. 8). The screen 739 may present a detailed view of the rovers 102 and docking stations 104, such as in the form of a table with a column for each rover 102 or docking station 104 owned by the healthcare facility or system. The table may also provide various data for each rover 102 or docking station 104, including, but not limited to, one or more of: descriptive data 740, serial number data 742, asset number data 744, assigned location data 746, last connection data 748, which may indicate the last time the rover 102 was docked with the docking station 104 or paired with a mobile device 286, and status data 750, which may indicate the current service needs of the rover 102 or docking station 104 (e.g., whether the rover 102 or docking station 104 currently requires service or is expected to require service soon).

[0132] As shown in the illustrated example, each rover 102 and docking station 104 may be associated with a user-interactive inspection request element 752 for requesting inspection for the rover 102 or docking station 104. FIG. 10 shows an inspection request window 754A that may be generated by the GUI in response to a user selection of the inspection request element 752 associated with a rover 102 indicated as requiring inspection. As shown in the illustrated example, the inspection request window 754A may include an information portion 756A indicating that an inspection is required for the rover 102. The inspection request window 754A may also include a usage history portion 758 indicating past usage of the rover 102, including relative usage data indicating the average number of rover 102 uses over the last four weeks, and a recent events portion 760 indicating recent events for the rover 102, such as recent errors and / or inspections. In this way, when a request is forwarded to an inspection team, the request is accompanied by a history of events and usage information that provides some context for the inspection team to address the issue requiring inspection.

[0133] Finally, the inspection request window 754A may also include a user-selectable "add to cart" element 762A that may be selected by the user to place the inspection request in the user's cart. The cart may generally serve as a temporary holding place for each inspection request desired by the user. In particular, once the user has identified and placed each desired inspection request in the cart, the user may then navigate to the cart by selecting the user-interactive cart element 752 and simultaneously submitting each of the inspection requests from the cart. FIG. 11 illustrates an inspection request window 754B that may be generated by a GUI response to user selection of the inspection request element 752 associated with a given docking station 104, and includes similar information and components as the inspection request window 754A.

[0134] 12 illustrates a screen 730 that may be presented by the GUI in response to a user selection of a user selectable element 726 that corresponds to a Type A rover module. While the figure illustrates an example screen for a Type A rover 102, it should be understood that the GUI may be configured to present a similar screen in response to selection of a user selectable element 727 that corresponds to a Type B rover 102 but comprises data specific to the Type B rover 102.

[0135] 12, the screen 730 may include user-interactive navigation elements 732, such as drop-down lists or the like, for navigating between different views of the aggregate data for the Type A rover 102. In the illustrated example, "Device Availability" is currently selected from the navigation elements 732.

[0136] The screen 730 may further include a rover summary portion 738, which may include information about Type A rovers 102 similar to the information about Type A rovers 102 provided in the rover summary portion 704 of the home screen 702 (FIG. 8). To this end, the rover summary portion 738 may include rover Type A rover data 708D indicating the number of Type A rovers 102 owned by the healthcare facility or system, response data 710D indicating the number of Type A rovers 102 currently requiring attention (e.g., maintenance), future response data 712D indicating the number of Type A rovers 102 requiring immediate attention, response requested data 714D indicating the number of Type A rovers 102 for which attention has already been requested, and unavailability data 716D indicating the number of Type A rovers 102 that are not currently available for use (e.g., non-functional). The rover summary portion 738 may also include available rover data 718D that indicates the number of Type A rovers 102 that are available for use and do not require attention and do not require immediate attention.

[0137] 13-17 show additional screens 772, 774, 776, 778, 780, 782 that may be generated by the GUI in response to a user selecting another view from a navigation element 732 in a Type-A rover module corresponding to user selectable element 726. Generally, each of the screens 772, 774, 776, 778, 780, 782 shown in these figures may present a different aspect of the aggregated data described above to provide a comprehensive understanding of the operation of the fleet of rovers 102. As shown in the illustrated example, each of the screens 772, 774, 776, 778, 780, 782 may include a user interactive navigation element 732 for navigating between the different screens 772, 774, 776, 778, 780, 782 to view different aspects of the aggregated data.

[0138] 13 may correspond to the selection of "Manifold" in navigation element 732 and may generally be configured to display aggregate manifold usage data across a population of rovers 102. To this end, screen 772 may include a graph 784 showing the number of each of one or more types of manifolds used by each of the rovers 102 over a given period of time, which may be set using a user-interactive period selector 786.

[0139] 14 may correspond to the selection of "Behavioral Insights" in the navigation element 732 and may generally be configured to display aggregate error code data across a population of rovers 102. To this end, the screen 774 may include a pie chart 788 showing the number and type of errors generated in the population of rovers 102 over a given period of time, which may be set using a user-interactive period selector 786. The screen 774 may also include total error data 790 indicating the total number of errors recorded over the given period of time, and may include average procedure length data 792 indicating the average length of procedures that a Type A rover 102 was used for over the given period of time, which may be determined based on the duration the rover 102 was operated to collect waste.

[0140] Screen 774 may further include a bar graph 794 that indicates the number of errors of a given type that occurred during each defined subperiod (e.g., months) of a given period (e.g., 52 weeks). The type of error represented by bar graph 794 may be selected via a user-interactive error type selector 796, which may be in the form of a drop-down menu. Screen 774 may also include a field 798 associated with error type selector 796, such that in response to a selection of a given error type via error type selector 796, field 798 may be updated to indicate the number of errors of the selected type that occurred over the given period.

[0141] 15 may correspond to the selection of "HEPA Filter" in the navigation element 732 and may generally be configured to display aggregate filter usage data across multiple Type A rovers 102. To this end, the screen 776 may include a bar graph 800 indicating the remaining life of the particulate filter 164 of each Type A rover 102 and / or whether the particulate filter 164 of each rover 102 requires replacement or is expected to require replacement soon. A similar screen may be provided by the GUI with respect to the aerosol filter 160.

[0142] 16A may correspond to a selection of "Rover ROI" in navigation element 732 and may generally be configured to display aggregate data on return on investment across a fleet of Type A rovers 102. To this end, screen 778 may include a plurality of data calculated by server 284 based on operational data received from Type A rovers 102, the data indicative of the return on investment achieved by Type A rovers 102. Such data may include, without limitation, total savings data 802 indicating the total amount of savings provided by Type A rovers 102 compared to alternative waste collection and disposal methods; red bag savings data 804 indicating savings in the disposal of red bag waste compared to alternative waste collection and disposal methods; time savings data 806 indicating the number of staff hours saved through increased efficiency compared to other waste collection and disposal methods; pollution prevention data 808 indicating the number of splashes / spills prevented compared to other waste collection and disposal methods; and carbon impact data 810 indicating the reduced amount of CO2 production compared to other waste collection and disposal methods.

[0143] 16B may correspond to the selection of "Rover ROI" in the navigation element 732 and may be configured to display further aggregate data generally related to the return on investment of a population of Type A rovers 102. To this end, the screen 778 may include a plurality of data, at least some of which may be calculated by the server 284 based on operational data received from the Type A rovers 102 related to the ROI for the Type A rovers 102. For example, the displayed data may include, without limitation, rover count data 812 indicating the number of Type A rovers 102 used by the healthcare facility or system, total manifolds data 814 indicating the number of manifolds 124 that may have been used over a given period of time, which may be set using the user-interactive period selector 786, and manifolds per day data 816 indicating the average number of manifolds 124 used per day over the given period of time. The screen 780 may also include a bar graph 818 indicating the age of the Type A rover 102 and the docking station 104 to which the Type A rover 102 may be docked, and may include a protection plan summary section 820 indicating the protection plan coverage for the Type A rover 102. The protection plan summary section 820 may include one or more data related to the protection plan coverage for the Type A rover 102, such as, without limitation, percentage coverage data 822 indicating the percentage of the Type A rover 102 that is covered by the protection plan, protection plan savings data 824 indicating the savings provided by the protection plan, and ROI data 826 indicating the return on investment of the protection plan.

[0144] 17 may correspond to a selection of "Vacuum Pump" in the navigation element 732 and may generally be configured to display vacuum pump runtime data across a population of Type A rovers 102. To this end, the screen 782 may include a bar graph 828 that shows the total runtime of each vacuum pump 113 on each of the Type A rovers 102 over a given period of time, which may be set using a user-interactive period selector 786.

[0145] It will be appreciated that the GUI may be configured to similarly present a similar screen showing aggregated data across multiple docking stations 104 of the rover management and notification systems 280A, 280B, such as when the user interactive element 728 corresponding to a docking station module is selected. Figure 18 shows a further screen 830 that may be presented by the GUI upon selection of the user interactive element 728 corresponding to a docking station module.

[0146] Screen 830 may include user-interactive navigation elements 832, such as in the form of a drop-down list, for navigating between different views of the aggregate data for docking station 104. In the illustrated example, "Device Availability" is currently selected from navigation element 832. In response to this selection, screen 830 may further include a docking station availability summary portion 834, which may include information about docking station 104 similar to the information provided in docking station summary portion 706 of home screen 702 (FIG. 8). To this end, docking station availability summary portion 834 may include docking station data 708E indicating the number of docking stations 104 used by the healthcare facility or system, capability data 710E indicating the number of docking stations 104 currently requiring attention (e.g., maintenance), future capability data 712E indicating the number of docking stations 104 expected to require immediate attention, capability requested data 714E indicating the number of docking stations 104 for which attention has already been requested, and unavailability data 716E indicating the number of docking stations 104 that are not currently available for use (e.g., non-functional). Docking station availability summary portion 834 may also include available docking station data 718E indicating the number of docking stations 104 that are available for use and do not require attention and are not expected to require immediate attention.

[0147] 19 shows another screen 840 that may be generated by the GUI in response to selection of "Cleaning Cycles" in the navigation element 832. Screen 840 may generally be configured to show aggregate cleaning cycle data across a population of rovers 102. To this end, screen 840 may include a bar graph 842 that shows the number of each of one or more types of cleaning cycles that have been performed on each of the rovers 102 over a given period of time, which may be set by a user-interactive period selector 786 present on screen 840.

[0148] 20 illustrates a further screen 843 that may be generated by the GUI in response to selection of "Facility Water Data" in navigation element 832. Screen 843 may include a table 844 showing a plurality of cleaning cycle data for each of the rovers 102 for a given facility. For example, without limitation, the cleaning cycle data may include one or more of: minimum flow rate data 846 indicating the minimum flow rate that occurred (experienced by each rover 102) for each rover 102 during a cleaning cycle over a set period of time; maximum flow rate data 848 indicating the maximum flow rate that occurred for each rover 102 during a cleaning cycle over a set period of time; final flow rate data 850 indicating the last flow rate that occurred for each rover 102 during a cleaning cycle over a set period of time; maximum water temperature data 852 indicating the highest water temperature that occurred for each rover 102 during a cleaning cycle over a set period of time; minimum water temperature data 854 indicating the lowest water temperature that occurred for each rover 102 during a cleaning cycle over a set period of time; and final water temperature data 856 indicating the last water temperature that occurred for each rover 102 during a cleaning cycle over a set period of time.

[0149] The present disclosure provides systems and methods for managing a fleet of rovers 102 owned by a healthcare facility or system in a manner unconventional in the industry. In particular, unlike traditional methods of recording the cleaning history of each system on a whiteboard or other physical tracking sheet, which results in disjointed, out-of-date data that fails to consider the medical device fleet as a whole, the present disclosure describes systems and methods that incorporate a specific combination of unconventional features, such as utilizing docking stations used to clean rovers as edge devices to enable communication between multiple rovers and a remote central processing system, to implement a centralized management and notification process for the fleet of rovers 102. Such a process may be configured to monitor the operation of the fleet of rovers as a whole to dynamically update maintenance and usage schedules for the fleet in real time, promoting both the longevity of individual rovers and efficient use of the fleet, and to provide a complete and up-to-date view of the fleet not available in previous methods. The systems and methods may also be configured to generate notifications to those best suited to take action based on such monitoring to enable rapid inspection and informed decision-making.

[0150] In general, the routines executed to implement aspects of the above description may be referred to herein as "computer program code," or simply "program code," whether implemented as part of an operating system or as a specific application, component, program, object, module, or sequence of instructions, or even a subset thereof. Program code may include computer-readable instructions that reside at different times in various memories and storage devices in the computer and that, when loaded and executed by one or more processors in the computer, cause the computer to perform the operations necessary to implement the acts and / or elements that embody various aspects of the description. The computer-readable program instructions for carrying out operations of various aspects of the description may be, for example, source code or object code written in assembly language or any combination of one or more programming languages.

[0151] The program code embodied in any of the applications / modules described herein may be individually or collectively distributed as a program product in a variety of different forms, in particular, the program code may be distributed using a computer-readable storage medium having computer-readable program instructions for causing a processor to perform the described aspects.

[0152] Computer-readable storage media that are non-transitory in nature may include volatile and non-volatile, removable and non-removable tangible media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer-readable storage media may also include random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid-state memory technology, portable compact disc read-only memory (CD-ROM) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be read by a computer. Computer-readable storage media should not be interpreted as transient signals themselves (e.g., radio waves or other propagating electromagnetic waves, electromagnetic waves propagating through a transmission medium such as a waveguide, or electrical signals transmitted through wires). The computer readable program instructions may be downloaded from the computer readable storage medium into a computer, another type of programmable data processing device, or another device, or downloaded over a network to an external computer or external storage device.

[0153] Computer-readable program instructions stored on a computer-readable medium may be used to instruct a computer, other type of programmable data processing apparatus, or other device to function in a specific manner to produce an article of manufacture including instructions that implement the functions / operations specified in the flowcharts, sequence diagrams, and / or block diagrams. The computer program instructions may be provided to one or more processors such that the instructions, when executed by the one or more processors, cause a series of calculations to be performed to implement the functions and / or operations specified in the flowcharts, sequence diagrams, and / or block diagrams described herein.

[0154] In some alternatives, the functions and / or acts illustrated in the flowcharts, sequence diagrams, and / or block diagrams may be reordered, processed sequentially, and / or processed simultaneously without departing from the scope of the invention. Additionally, any of the flowcharts, sequence diagrams, and / or block diagrams may include more or fewer blocks than illustrated therein.

[0155] The terminology used herein is for the purpose of describing particular examples only and is not intended to be limiting. As used herein, the singular is intended to include the plural unless the context clearly dictates otherwise. The terms "comprises" and / or "comprises," when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Furthermore, to the extent that the terms "comprises," "has," "comprises," "consisting of," or variations thereof, are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprises."

[0156] While a description of various examples has been provided, and these examples have been described in considerable detail, it is not the intention of applicants to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will be readily apparent to those skilled in the art. Accordingly, the invention in its broader aspects is not limited to the specific details, representative apparatus and methods, and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit and scope of applicants' general inventive concept.

[0157] Clause 1. A method for managing a medical waste collection unit including a canister for holding medical waste, the medical waste collection unit being capable of being coupled to a docking station for emptying and cleaning the canister, the method including: resetting a counter or timer for the medical waste collection unit in response to the canister of the medical waste collection unit being cleaned by the docking station; indexing the counter or starting the timer in response to each instance the medical waste collection unit is activated to draw medical waste into the canister using a vacuum source; comparing the counter to a preset value or comparing the timer to a first preset duration (period) since a previous cleaning of the canister by the docking station; and based on the comparison, triggering a notification instructing a user to have the docking station clean the medical waste collection unit.

[0158] Clause 2. The method of clause 1, further comprising resetting a counter or timer in response to the canister of the medical waste collection unit being cleaned in an extended cleaning cycle in which fluid from the docking station is sprayed into the canister for a duration longer than a second preset duration associated with another cleaning cycle of the docking station, wherein the preset value defines the number of extended cleaning cycles or the first preset duration defines the duration since a previous extended cleaning cycle of the canister, and the notification instructs the user to have the docking station clean the medical waste collection unit in the extended cleaning cycle.

[0159] Clause 3. The method of clause 2, further comprising not resetting the counter or timer in response to the canister of the medical waste collection unit being cleaned by the docking station in another cleaning cycle.

[0160] Clause 4. The method of clause 3, further comprising determining a ratio of the number of times the canister is cleaned by the docking station in a long cleaning cycle to the number of times the canister is cleaned by the docking station in another cleaning cycle, comparing the ratio to a preset ratio, and triggering a notification based on the comparison.

[0161] Clause 5. The method of any one of clauses 2 to 4, further comprising displaying, on one or more displays, a graphical user interface including one or more user-selectable options (choices) related to the extended cleaning cycle, the one or more user-selectable options configured to set at least one of fill level, canister soak time (soak time), detergent volume, detergent addition timing, water pressure, water temperature, ingredient addition, or ultraviolet light activation to be implemented in subsequent instances when the medical waste collection unit is cleaned in the extended cleaning cycle.

[0162] Clause 6. The method of any one of clauses 1 to 5, further comprising displaying, on one or more displays, a graphical user interface including one or more user-selectable options for setting the preset value and / or the first preset duration.

[0163] Clause 7. The method of clause 5 or 6, wherein the one or more displays include a display on the medical waste collection unit and / or a display on a personal computing device remote from the medical waste collection unit.

[0164] Clause 8. The method of any one of clauses 1 to 7, further comprising triggering the display of a notification on a display of the medical waste collection unit.

[0165] Clause 9. The method of clause 8, further comprising triggering the display of a notification on a display of the medical waste collection unit so that the notification is displayed when the medical waste collection unit is not activated to collect medical waste, the notification instructing the user to have the docking station clean the medical waste collection unit before starting another waste collection operation.

[0166] Clause 10. The method of clause 8 or 9, further comprising triggering the display of a notification on a display of the medical waste collection unit, such that the notification is displayed in response to the medical waste collection unit leaving an idle state.

[0167] Clause 11. The method of any one of clauses 7 to 10, further comprising triggering the display of a notification on a display of the medical waste collection unit, such that the notification is displayed in response to the medical waste collection unit docking to the docking station.

[0168] Clause 12. The method of clause 11, wherein triggering the display of a notification on a display of the medical waste collection unit such that the notification is displayed in response to the medical waste collection unit being docked to the docking station includes communicating, by the remote processing system, notification data to the docking station via one or more computer networks in response to the medical waste collection unit being docked to the docking station, the notification data causing the docking station to instruct the medical waste collection unit to display the notification.

[0169] Clause 13. The method of clause 12, further comprising receiving, by the remote processing system, a status update from the docking station indicating a docked status of the medical waste collection unit in response to the medical waste collection unit being docked to the docking station, and communicating, by the remote processing system, notification data to the docking station in response to receiving the status update.

[0170] Clause 14. The method of clause 13, further comprising receiving, by the remote processing system, a request for the status of the medical waste collection unit from a personal computing device remote from the medical waste collection unit, and in response to receiving the request, communicating, by the remote processing system, status data to the personal computing device indicating that the medical waste collection unit has docked to the docking station.

[0171] Clause 15. The method of any one of clauses 1-14, further comprising receiving, by the remote processing system, updated cleaning data for the medical waste collection unit from the docking station via one or more computer networks in response to the canister of the medical waste collection unit being cleaned by the docking station.

[0172] Clause 16. The method of clause 15, wherein the updated cleaning data includes one or more of a counter for the medical waste collection unit, a timer for the medical waste collection unit, or at least one characteristic of the last cleaning cycle performed on the medical waste collection unit.

[0173] Clause 17. The method of clause 15 or 16, wherein the updated cleaning data is communicated from the medical waste collection unit to the docking station in response to the medical waste collection unit being docked to the docking station and / or in response to a canister of the medical waste collection unit being cleaned by the docking station.

[0174] Clause 18. The method of any one of clauses 1 to 17, wherein the medical waste collection unit is a first medical waste collection unit, and further comprising generating a ranked list of relative cleanliness of the population of medical waste collection units including the first medical waste collection unit based on indexing a counter or starting a timer for each of the medical waste collection units in response to each instance the medical waste collection unit is activated to draw medical waste into the canister of the medical waste collection unit using a vacuum source, and providing the ranked list for display on the medical waste collection unit and / or on a personal computing device remote from the medical waste collection unit.

[0175] Clause 19. The method of clause 18, wherein a display is mounted on a movable chassis of the first medical waste collection unit, and optionally, data indicating a ranked list of relative cleanliness is transmitted from the remote processing system to the medical waste collection unit via one or more computer networks for display on the display mounted on the chassis.

[0176] Clause 20. The method of clause 19, wherein the data is transferred (pushed) to each of the medical waste collection units of the population so that it can be selectively viewed on a display mounted on the chassis of the medical waste collection unit.

[0177] Clause 21. The method of any one of clauses 1 to 20, further comprising triggering the display of a notification on a display of a personal computing device remote from the medical waste collection unit.

[0178] Clause 22. A method for managing a population of medical waste collection units, each including a canister for holding medical waste, the medical waste collection units being interchangeably coupleable with a docking station for emptying and cleaning the canisters, the method including: receiving first usage data from a first medical waste collection unit indicating a duration for which the first medical waste collection unit is operated to draw medical waste into the canister of the first medical waste collection unit by a vacuum source; receiving second usage data from a second medical waste collection unit indicating a duration for which the second medical waste collection unit is operated to draw medical waste into the canister of the second medical waste collection unit by the vacuum source; comparing the first usage data with the second usage data to identify relative usage data for the first medical waste collection unit and the second medical waste collection unit; comparing the relative usage data to a predetermined relative usage threshold; and triggering a notification based on the comparison.

[0179] Clause 23. The method of clause 22, wherein the notification instructs the user to use the less frequently used one of the first medical waste collection unit and the second medical waste collection unit in a subsequent medical waste collection procedure.

[0180] Clause 24. The method of clause 22 or 23, further comprising triggering the display of a notification on a first display mounted on the chassis of the first medical waste collection unit in response to the first medical waste collection unit leaving an idle state, and / or on a second display mounted on the chassis of the second medical waste collection unit in response to the second medical waste collection unit leaving an idle state.

[0181] Clause 25. The method of clause 24, further comprising receiving, by a processing system remote from the first and / or second medical waste collection units (remote processing system), a status update from one of the first and second medical waste collection units indicating a non-idle status of one of the first and second medical waste collection units in response to one of the first and second medical waste collection units leaving an idle state, and communicating, by the remote processing system, notification data to one of the first and second medical waste collection units in response to receiving the status update, wherein the notification data causes one of the first and second medical waste collection units to display a notification.

[0182] Clause 26. The method of clause 24 or 25, further comprising transmitting, by a processing system remote from the first and / or second medical waste collection units, the relative usage data to the first and / or second medical waste collection units via one or more computer networks for selective viewing on the first and / or second displays, respectively.

[0183] Clause 27. The method of any one of clauses 24-26, further comprising transmitting, by a processing system remote from the first and / or second medical waste collection units, the relative usage data to the first medical waste collection unit via one or more computer networks in response to the first medical waste collection unit docking with the docking station, and / or to the second medical waste collection unit via one or more computer networks in response to the second medical waste collection unit docking with the docking station.

[0184] Clause 28. The method of any one of clauses 22 to 27, further comprising triggering the display of a notification on a display of a more frequently used one of the first and second medical waste collection units.

[0185] Clause 29. The method of any one of clauses 22 to 28, further comprising triggering the display of a notification on a display of a personal computing device remote from the first and second medical waste collection units.

[0186] Clause 30. The method of any one of clauses 22 to 29, further comprising generating a ranked list of relative uses (relative uses) of the first medical waste collection unit, the second medical waste collection unit, and the additional medical waste collection unit of the population, and enabling selective display of the ranked list of relative uses.

[0187] Clause 31. The method of any one of clauses 22 to 30, further comprising: determining a relative usage ratio based on the first usage data and the second usage data; comparing the relative usage ratio to a pre-set usage ratio; and triggering display of a notification based on the comparison.

[0188] Clause 32. The method of clause 31, wherein the predetermined ratio is at least 150 percent.

[0189] Clause 33. The method of any one of clauses 22 to 32, wherein the notification is further configured to instruct the user to dock a frequently used one of the first and second medical waste collection units with the docking station for cleaning.

[0190] Clause 34. A method of managing a medical waste collection unit including a canister for holding medical waste and an aerosol removal unit including a filter having an expected filter life, the method including: resetting a filter timer for the medical waste collection unit in response to a filter replacement event; starting the filter timer in response to each instance the medical waste collection unit is activated to draw fluid through the filter; and triggering the display of a notice on a display of a personal computing device remote from the medical waste collection unit instructing a user to replace the filter based on the filter timer and the expected filter life.

[0191] Clause 35. The method of clause 34, further comprising: determining a filter usage threshold based on a preset percentage of expected filter life; and triggering the display of a notification on the personal computing device based on the filter timer and the filter usage threshold.

[0192] Clause 36. The method of clause 35, further comprising displaying a graphical user interface on a display of the personal computing device and / or on a display of the medical waste collection unit, the graphical user interface including one or more user-selectable options for setting the expected filter life and / or the preset percentage.

[0193] Clause 37. The method of any one of clauses 34 to 36, wherein the aerosol removal unit includes an aerosol sensor configured to generate a signal indicating whether aerosol is being drawn through the filter, and the method further includes starting a filter timer in response to each instance in which the signal from the aerosol sensor indicates that aerosol is being drawn through the filter.

[0194] Clause 38. The method of clause 37, wherein the aerosol sensor comprises a smoke sensor and the filter comprises a smoke filter, optionally a ULPA filter.

[0195] Clause 39. The method of any one of clauses 34 to 36, wherein the filter comprises a smoke filter, optionally a ULPA filter.

[0196] Clause 40. The method of any one of clauses 34 to 39, wherein the filter comprises a HEPA filter.

[0197] Clause 41. The method of any one of clauses 34 to 40, further comprising providing at least one of a filter timer or remaining filter life for display on a display on the personal computing device and / or a display of the medical waste collection unit.

[0198] Clause 42. The method of any one of clauses 34 to 41, wherein the medical waste collection unit is capable of being coupled to a docking station for emptying and cleaning the canister, and the method further includes, at a processing system remote from the medical waste collection unit, receiving filter usage data for the medical waste collection unit from the docking station via one or more computer networks in response to the medical waste collection unit docking with the docking station; aggregating, by the remote processing system, the received filter usage data with filter usage data from other medical waste collection units to generate aggregated filter usage data; and communicating, by the remote processing system, the aggregated filter usage data to the personal computing device for display on the personal computing device display.

[0199] Clause 43. The method of clause 42, wherein the filter usage data includes a filter timer and / or an expected filter life.

[0200] Clause 44. The method of clause 42 or 43, wherein the filter usage data includes a profile assigned to each use of the filter during a medical procedure, the profile including one or more data selected from the group consisting of date of use, time of use, medical specialty, type of procedure, medical waste collection unit part number, and filter part number.

[0201] Clause 45. A method of managing a population of medical waste collection units, each including a canister for holding medical waste and a manifold receptacle configured to receive an interchangeable manifold, the method including: receiving usage data from each of the medical waste collection units; aggregating the received usage data to generate aggregate usage data indicative of usage characteristics across the population of medical waste collection units; and providing the aggregate usage data for display on a display of a personal computing device remote from the medical waste collection units.

[0202] Clause 46. The method of clause 45, wherein each of the medical waste collection units includes a fluid measurement system, and the usage data from each medical waste collection unit includes a fluid waste volume measured by the fluid measurement system of the medical waste collection unit for each use of the replacement manifold during the medical procedure.

[0203] Clause 47. The method of clause 46, including identifying a fluid disposal cost based on a fluid disposal volume and a weight-based disposal cost conversion, comparing the fluid disposal cost to an operating cost of a medical waste collection unit to identify cost savings, and providing the cost savings for display on a remote personal computing device.

[0204] Clause 48. The method according to any one of clauses 45 to 47, wherein the usage data from each medical waste collection unit includes a profile assigned to each use of the exchange manifold by the medical waste collection unit during a medical procedure.

[0205] Clause 49. The method of clause 48, wherein the profile assigned to each use of the interchangeable manifold includes one or more data selected from the group consisting of date of use, time of use, medical specialty, type of procedure, medical waste collection unit type and / or model number, a unique identifier of the medical waste collection unit, and manifold type and / or model number, and a unique identifier of the manifold.

[0206] Clause 50. The method of any one of clauses 45 to 49, wherein the medical waste collection units are interchangeably coupleable with docking stations for emptying and cleaning the canisters of each medical waste collection unit, and the method further includes receiving, at a processing system remote from the medical waste collection units and via one or more computer networks, usage data for each of the medical waste collection units from the docking station in response to the medical waste collection units docking with the docking station.

[0207] Clause 51. A method for managing a population of medical waste collection units, each including a canister for holding medical waste, the method including: receiving error code data for each of the medical waste collection units, the error code data indicating one or more error codes generated by the medical waste collection units based on anomalies identified during operation of the medical waste collection units; aggregating the received error code data to generate aggregate error code data indicative of a diagnostic pattern across the population of medical waste collection units; and providing the aggregate error code data for display on a personal computing device remote from the medical waste collection units.

[0208] Clause 52. The method of clause 51, wherein the error code data from each of the medical waste collection units includes one or more data selected from the group consisting of date of use, time of use, medical specialty, type of procedure, type and / or model of the medical waste collection unit, and a unique identifier of the medical waste collection unit.

[0209] Clause 53. The method of clause 51 or 52, wherein the medical waste collection units are interchangeably coupleable with a docking station for emptying and cleaning the canisters of each of the medical waste collection units, and the method further includes, at a processing system remote from the medical waste collection units, receiving error code data for each of the medical waste collection units from the docking station in response to the medical waste collection units docking with the docking station.

[0210] Clause 54. A method of managing operation of a medical waste collection unit including a canister for holding medical waste and configured to be removably coupled to a docking station for emptying and cleaning the canister of the medical waste collection unit, the method comprising: in response to the medical waste collection unit docking to the docking station to perform a cleaning cycle on the canister of the medical waste collection unit, receiving, at a processing system remote from the medical waste collection unit and via one or more computer networks, a status update from the docking station indicating that the medical waste collection unit is docked to the docking station; in response to receiving the status update, determining by the remote processing system that a notification should be triggered; and in response to determining that a notification should be triggered, triggering a notification by the remote processing system.

[0211] Clause 55. The method of clause 44, further comprising triggering a notification to be displayed on a display of the medical waste collection unit and / or triggering a notification on a display of a personal computing device remote from the medical waste collection unit by transmitting notification data to the docking station via one or more computer networks, the notification data causing the docking station to instruct the medical waste collection unit to display the notification.

[0212] Clause 56. The method of clause 54 or 55, further comprising receiving, at the remote processing system, operational data relating to operation of the medical waste collection unit in response to the medical waste collection unit docking to the docking station to clean the canister of the medical waste collection unit, and determining, by the remote processing system, based on the operational data, that a notification should be triggered.

[0213] Clause 57. The method of clause 56, further comprising, in response to receiving the operational data, aggregating the operational data with operational data received from other medical collection units when docked at the docking station to generate aggregated operational data, and determining that a notification should be triggered based on the aggregated operational data.

[0214] Clause 58. The method of clause 57, further comprising providing operational data for the medical waste collection unit and / or aggregate operational data for presentation on a display of a personal computing device remote from the medical waste collection unit.

[0215] Clause 59. The method of any one of clauses 54 to 58, wherein the operational data for the medical waste collection unit includes one or more of cleaning-related data for the medical waste collection unit, error code data for the medical waste collection unit, filter usage data for the medical waste collection unit, vacuum pump runtime data for the medical waste collection unit, manifold usage data for the medical waste collection unit, or fluid waste volume data for the medical waste collection unit.

[0216] Clause 60. The method of any one of clauses 54 to 59, further comprising receiving, at the remote processing system, cleaning data for the medical waste collection unit from the docking station in response to a cleaning cycle being performed on the medical waste collection unit, determining, by the remote processing system, based on the cleaning data, that a cleaning-related notification should be displayed on the medical waste collection unit, and triggering, by the remote processing system, display of the cleaning-related notification on a display of the medical waste collection unit in response to subsequent docking of the medical waste collection unit with the docking station.

[0217] Clause 61. A method for managing operation of a population of medical waste collection units, each including a canister for holding medical waste and configured to be removably coupled to a docking station for emptying and cleaning the canisters of the medical waste collection units, the method comprising: in response to the medical waste collection unit docking to the docking station to perform a cleaning cycle on the canister of the medical waste collection unit, receiving operational data related to operation of the medical waste collection unit from the docking station at a processing system remote from the medical waste collection unit and via one or more computer networks; in response to receiving the operational data, aggregating, by the remote processing system, the operational data with operational data received from other medical collection units when docked to the docking station to generate aggregated operational data; and providing, by the remote processing system, the operational data and / or aggregated operational data (aggregated operational data) for presentation on a display of a personal computing device remote from the medical waste collection unit.

[0218] Clause 62. The method of clause 61, wherein the operational data for the medical waste collection unit includes one or more of cleaning-related data for the medical waste collection unit, error code data for the medical waste collection unit, filter usage data for the medical waste collection unit, vacuum pump runtime data for the medical waste collection unit, manifold usage data for the medical waste collection unit, or fluid waste volume data for the medical waste collection unit.

[0219] Clause 63. A computer program product stored in a non-transitory memory, comprising computer-executable instructions configured, when executed by at least one controller or processor, to perform the method of any one of clauses 1 to 62.

[0220] Clause 64. At least one control device (controller) or processor configured to carry out the method according to any one of clauses 1 to 62.

[0221] Clause 65. A system for managing the operation of a medical waste collection unit including a canister for holding medical waste, the system including: a remote processing system; and a docking station for cleaning the canister of the medical waste collection unit, the docking station configured to communicate with the remote processing system via one or more computer networks and to be removably coupled to the medical waste collection unit to form a fluid connection and a data connection with the medical waste collection unit, and in response to being coupled to the medical waste collection unit, the docking station performs a cleaning cycle in which fluid is supplied from the docking station to the medical waste collection unit via the fluid connection to be sprayed into the canister of the medical waste collection unit, communicate status updates to the remote processing system indicating the docked status of the medical waste collection unit, receive notification data from the remote processing unit in response to the status update indicating whether a notification should be displayed on the medical waste collection unit, and trigger the medical waste collection unit to display the notification using the data connection based on the notification data.

[0222] Clause 66. The system of clause 65, wherein in response to being coupled to the medical waste collection unit, the docking station is further configured to receive operational data relating to operation of the medical waste collection unit via the data connection and to communicate the operational data via one or more computer networks to a remote processing system, the remote processing system being configured to generate notification data based on the operational data for the medical waste collection unit.

[0223] Clause 67. The system of clause 66, wherein the remote processing system is configured, in response to receiving the operation data, to aggregate the operation data with operation data received from another medical waste collection unit when docked at the docking station to generate aggregate operation data, and to trigger notification data based on the aggregate operation data.

[0224] Clause 68. The system of clause 67, wherein the remote processing system is configured to provide operational data and / or aggregated operational data for the medical waste collection unit for presentation on a display of a personal computing device remote from the medical waste collection unit.

[0225] Clause 69. The system of any one of clauses 65 to 68, wherein the operational data for the medical waste collection unit includes one or more of cleaning-related data for the medical waste collection unit, error code data for the medical waste collection unit, filter usage data for the medical waste collection unit, vacuum pump runtime data for the medical waste collection unit, manifold usage data for the medical waste collection unit, or fluid waste volume data for the medical waste collection unit.

[0226] Clause 70. A system described in any one of clauses 65 to 69, wherein in response to a cleaning cycle being performed on the medical waste collection unit, the docking station is configured to communicate cleaning-related data for the medical waste collection unit to the remote processing system via one or more computer networks, and the remote processing system is configured to trigger the display of a cleaning-related notification on the medical waste collection unit upon subsequent docking of the medical waste collection unit with the docking station based on the cleaning-related data.

[0227] Clause 71. A system for managing a population of medical waste collection units, each including a canister for collecting medical waste, the system including a remote processing system and a docking station for cleaning the canisters of the medical waste collection units, the docking station configured to communicate with the remote processing system via one or more computer networks and to be removably coupled to each of the medical waste collection units to form fluid and data connections with the medical waste collection units, and in response to being coupled to one of the medical waste collection units, the docking station is configured to perform a cleaning cycle in which fluid is supplied from the docking station to the medical waste collection unit via the fluid connection for spraying into the canister of the medical waste collection unit, receive operational data from the medical waste collection units via the data connection and transmit the operational data to the remote processing system, and the remote processing system is configured to aggregate the operational data for each of the medical waste collection units received from the docking station and provide the aggregated operational data for display on the medical waste collection unit and / or on a personal computing device remote from the medical waste collection units.

[0228] Clause 72. The system of clause 71, wherein the remote processing system is configured to transmit the aggregate operational data to the docking station for presentation on a display of each of the medical waste collection units in response to the medical waste collection units subsequently being coupled to the docking station.

[0229] Clause 73. The system of clause 71 or 72, wherein the operational data for the medical waste collection unit includes one or more of cleaning-related data for the medical waste collection unit, error code data for the medical waste collection unit, filter usage data for the medical waste collection unit, vacuum pump runtime data for the medical waste collection unit, manifold usage data for the medical waste collection unit, or fluid waste volume data for the medical waste collection unit.

Claims

1. A method for maintaining a medical waste collection unit, including a canister for collecting medical waste generated during surgical procedures, Transporting the medical waste collection unit containing the collected medical waste to a docking station, wherein the docking station includes a supply line coupled to a first interface to establish a fluid supply connection with the medical waste collection unit when docked with the docking station, a discharge line coupled to a second interface to establish a fluid discharge connection with the medical waste collection unit when docked with the docking station, a first communication interface to establish a first data connection with the medical waste collection unit when docked with the docking station, and a second communication interface to establish a second data connection with a remote processing system. Docking the medical waste collection unit to the docking station in order to form the fluid supply connection, the fluid discharge connection, and the first data connection, The cleaning cycle is performed in the medical waste collection unit, wherein in the cleaning cycle, a cleaning fluid is supplied from the supply line of the docking station to the medical waste collection unit through the fluid supply connection and sprayed into the canister, and the waste material is discharged from the canister to the discharge line of the docking station through the fluid discharge connection. A status update indicating the docked status of the medical waste collection unit is communicated from the docking station and through the second data connection to the remote processing system. Receiving notification data from the remote processing system in response to the status update, at the docking station and through the second data connection, wherein the notification data indicates a maintenance notification displayed on the medical waste collection unit, and the receiving of such data. The medical waste collection unit is triggered by the docking station and through the first data connection to display a maintenance notification based on the notification data. Methods that include...

2. The remote processing system tracks a metric for determining whether the medical waste collection unit triggers the maintenance notification, The remote processing system receives operational data from the medical waste collection unit, The remote processing system identifies a notification threshold based on the operational data, The notification data is generated based on the metric and the notification threshold, Includes, The method according to claim 1, wherein the operation data indicates surgical data of the medical waste collection unit and / or cleaning cycle data of the medical waste collection unit.

3. When the vacuum source of the medical waste collection unit draws waste material into the canister, a video feed of the canister and the waste material placed inside the canister is captured by an imaging device supported by an apparatus cradle coupled to the canister. The image frame of the video feed is analyzed by the imaging device or the remote processing system to identify visual data indicating at least one of the degree of occlusion, the composition of the waste material, and the storage time of the waste material. The remote processing system identifies the notification threshold based on the visual data, The method according to claim 2, including the method described in claim 2.

4. When docked to the docking station, the remote processing system aggregates the operational data of the medical waste collection unit with operational data received from another medical waste collection unit in order to generate aggregated operational data. The remote processing system generates the notification data based on the aggregated operation data, The method according to claim 2, including the method described in claim 2.

5. Based on the aggregated data, a ranked list of the relative cleanliness of a group of medical waste collection units, including the aforementioned medical waste collection unit and the aforementioned other medical waste collection unit, is generated. To provide the ranked list for display on the medical waste collection unit and / or on a personal computing device remotely from the medical waste collection unit, The method according to claim 4, including the method described in claim 4.

6. The remote processing system determines, based on the aggregated data, that the medical waste collection unit is used more frequently than the other medical waste collection unit, In response to determining that the medical waste collection unit is being used more frequently, the remote processing system and the second data connection communicate further notification data indicating a usage notification displayed on the medical waste collection unit, instructing the user to use the other medical waste collection unit in subsequent procedures. The docking station and, through the first data connection, trigger the medical waste collection unit to display the usage notification based on the further notification data, The method according to claim 4, including the method described in claim 4.

7. The method according to any one of claims 1 to 6, wherein the maintenance notification instructs to perform a long cleaning cycle in the medical waste collection unit, and in the long cleaning cycle, the cleaning fluid from the docking station's supply line is sprayed into the canister for a duration longer than the duration associated with another cleaning cycle available from the docking station to the medical waste collection unit.

8. The remote processing system tracks the cleaning cycle metric to determine whether to trigger the maintenance notification instructing the execution of the aforementioned long-duration cleaning cycle, The medical waste collection unit performs the long-duration cleaning cycle, In response to the medical waste collection unit performing the long-duration cleaning cycle, the remote processing system resets the cleaning cycle metric. The medical waste collection unit performs the other cleaning cycle, Includes, The method according to claim 7, wherein the cleaning cycle metric is not reset in response to performing the other cleaning cycle.

9. The method according to claim 8, wherein the cleaning cycle metric includes the ratio of the number of times the canister is cleaned by the docking station in another cleaning cycle to the number of times the canister is cleaned by the docking station in the long cleaning cycle.

10. The method according to any one of claims 1 to 6, wherein the execution of the cleaning cycle and the communication of the operation data occur during the first docking of the medical waste collection unit with the docking station, and the triggering of the medical waste collection unit by the docking station to display the maintenance notice occurs during the subsequent docking of the medical waste collection unit with the docking station.

11. In response to performing the aforementioned cleaning cycle, the locally stored cleaning cycle metric is reset by the medical waste collection unit in order to determine whether to display a notification instructing to perform a further cleaning cycle. The locally stored cleaning cycle metric is compared by the medical waste collection unit with the cleaning notification threshold. Based on the comparison, the medical waste collection unit displays the notification instructing to perform the further cleaning cycle, A method according to any one of claims 1 to 6, including the method described in any one of claims 1 to 6.

12. The method according to claim 11, wherein the cleaning notification threshold is dynamically adjusted by the medical waste collection unit based on operational data of the medical waste collection unit recorded during at least one surgical procedure.

13. The method according to any one of claims 1 to 6, wherein the medical waste collection unit includes an aerosol removal unit including a filter, and the maintenance notice instructs to replace the filter.

14. The aerosol removal unit includes an aerosol sensor configured to generate a signal indicating whether an aerosol is being drawn in through the filter, The aforementioned method, The filter metric is tracked by the remote processing system to determine whether to instruct the system to replace the filter based on the aforementioned signal. The remote processing system generates the notification data based on the filter metric, The method according to claim 13, including the method described in claim 13.

15. The method according to any one of claims 1 to 6, comprising triggering the display of a second notification corresponding to the notification on a personal computing device remotely from the medical waste collection unit by the remote processing system.

16. The method according to any one of claims 1 to 6, comprising causing the medical waste collection unit to display the notification during the cleaning cycle.

17. A medical waste collection unit including a canister for collecting medical waste generated during surgical procedures, docking station and A medical waste collection system including, The docking station is, A supply line coupled to a first interface to establish a fluid supply connection with the medical waste collection unit when docked with the docking station, A discharge line coupled to a second interface to establish a fluid discharge connection with the medical waste collection unit when docked with the docking station, A first communication interface for establishing a first data connection with the medical waste collection unit when docked to the docking station, A second communication interface for establishing a second data connection with the remote processing system, Includes, The docking station, when docked with the medical waste collection unit, performs a cleaning cycle, wherein in the cleaning cycle, a cleaning fluid is supplied from the supply line of the docking station to the medical waste collection unit through the fluid supply connection and sprayed into the canister, and in the cleaning cycle, waste material is discharged from the canister to the discharge line of the docking station through the fluid discharge connection. A status update indicating the docked status of the medical waste collection unit is communicated to the remote processing system via the second data connection. Receiving notification data from the remote processing system via the second data connection in response to the status update, wherein the notification data indicates a maintenance notification displayed on the medical waste collection unit, and the receiving of such data. To trigger the medical waste collection unit through the first data connection in order to display a maintenance notification based on the notification data, It is configured to do so Medical waste collection system.

Images