WO2022241039A1

WO2022241039A1 - Building management system with code blue integration

Info

Publication number: WO2022241039A1
Application number: PCT/US2022/028842
Authority: WO
Inventors: Julie J. Brown; Brendon F. BUCKLEY; Matthew F. Malcolm
Original assignee: Johnson Controls Tyco IP Holdings LLP
Priority date: 2021-05-12
Filing date: 2022-05-11
Publication date: 2022-11-17
Also published as: CA3219213A1; EP4338016A1

Abstract

A building management system (BMS) of a building for controlling a healthcare facility. The BMS including one or more processing circuits comprising one or more memory devices configured to store instructions thereon that, when executed by one or more processors, cause the one or more processors to: receive a signal indicating a code blue event in a room for a patient; and adjust at least one of a temperature, a pressure, a humidity level, a lighting system, or an air composition in the room automatically in response to the received signal.

Description

BUILDING MANAGEMENT SYSTEM WITH CODE BLUE INTEGRATION

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63/187,842, filed on May 12, 2021, and U.S. Patent Application No. 17/737,876, filed on May 5, 2022. The entire contents of all applications listed above are incorporated by reference herein.

BACKGROUND

[0002] The present disclosure relates generally to building management systems (BMS). More specifically, the present disclosure relates generally to BMS systems with an integrated command center.

SUMMARY

[0003] This summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the devices or processes described herein will become apparent in the detailed description set forth herein, taken in conjunction with the accompanying figures, wherein like reference numerals refer to like elements.

[0004] One implementation of the present disclosure is a building management system (BMS) of a building for controlling a healthcare facility. The BMS includes one or more processing circuits comprising one or more memory devices configured to store instructions thereon that, when executed by one or more processors, cause the one or more processors to: receive a signal indicating a code blue event in a room for a patient; and adjust at least one of a temperature, a pressure, a humidity level, a lighting system, or an air composition in the room automatically in response to the received signal.

[0005] Another implementation of the present disclosure is an integration engine of a building management system. The integration engine includes one or more processing circuits located on-premises and comprising one or more memory devices coupled to one or more processors, the one or more memory devices configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: receive nurse call information from a nurse call system; determine a code blue identifier based on the nurse call information; determine a room identifier based on the nurse call 1 information; determine that an active code blue event is occurring based on the code blue identifier; determine a room location where the active code blue event is occurring based on the room identifier; initiate a code blue event response; and automatically implement a set of code blue actions in response to initiating the code blue event response directly without control of any off-premises processing circuits, the set of code blue actions including controlling at least one of a room heating ventilation, and air conditioning (HVAC) system or a lighting system.

[0006] Another implementation of the present disclosure is a method of operating an integration engine. The method includes receiving nurse call information indicating a code blue event is occurring in a room for a patient; and adjusting at least one of a temperature, pressure, or humidity level in the room automatically in response to the nurse call information.

[0007] In some embodiments, the processor is further configured to receive live video feed of the inside of the room and automatically provide a notification to a care team member for the room in response to determining the patient has been injured.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. l is a schematic drawing of a building equipped with an HVAC system, according to some embodiments.

[0009] FIG. 2 is a schematic drawing of a waterside system which can be used as part of the HVAC system of FIG. 1, according to some embodiments.

[0010] FIG. 3 is a block diagram of an airside system which can be used as part of the HVAC system of FIG. 1, according to some embodiments.

[0011] FIG. 4 is a block diagram of a BMS which can be used in the building of FIG. 1, according to some embodiments.

[0012] FIG. 5 is a block diagram of an integrated command center, which can be implemented in the building of FIG. 1, according to some embodiments.

[0013] FIG. 6 is a block diagram of a command center engine, which can be implemented in the integrated command center of FIG. 5, according to some embodiment. 2 [0014] FIG. 7 is a block diagram of a command center engine with early warning system, which can be implemented in the integrated command center of FIG. 5, according to some embodiments.

[0015] FIG. 8 is a block diagram of a command center with integrated parking control, which can be implemented in the integrated command center of FIG. 5, according to some embodiments.

[0016] FIG. 9 is a block diagram of a command center engine with distributed care functionality, which can be implemented in the integrated command center of FIG. 5, according to some embodiments.

[0017] FIG. 10 is a block diagram of a command center engine with sentient patient room functionality, which can be implemented in the integrated command center of FIG. 5, according to some embodiments.

[0018] FIG. 11 is a block diagram of a command center engine with smart room integration, which can be implemented in the integrated command center of FIG. 5, according to some embodiments.

[0019] FIG. 12 is a block diagram of a command center engine with patient recognition functionality, which can be implemented in the integrated command center of FIG. 5, according to some embodiments.

[0020] FIG. 13 is a diagram for implementing proper response to a patient during an emergency, which can be implemented by the engine of FIG. 5, according to some embodiments.

[0021] FIG. 14 is a diagram for implementing proper response to a patient during an emergency, which can be implemented by the engine of FIG. 5, according to some embodiments.

[0022] FIG. 15 is a schematic diagram of an intelligent code blue system architecture, which can be implemented by the engine of FIG. 5, according to some embodiments.

[0023] FIG. 16 is a flow diagram of a code blue response method, which can be implemented by the engine of FIG. 5, according to some embodiments. 3 [0024] FIG. 17 is a schematic diagram of an intelligent code blue system architecture, which can be implemented by the engine of FIG. 5, according to some embodiments.

DETAILED DESCRIPTION

Overview

[0025] Referring generally to the FIGURES, systems and methods for aggregating data from multiple subsystems and making one or more command decisions based on the aggregated data. In some embodiments, buildings - such as hospitals - include several systems and/or subsystems, such as heating, ventilation, or air conditioning (HVAC) systems, room scheduling systems, patient monitoring systems, ambulance dispatch systems, and distributed care systems.

Building Management System and HVAC System

[0026] Referring now to FIG. 1, a perspective view of a building 10 (e.g., a hospital or healthcare facility) is shown. Building 10 is served by a building management system (BMS). A BMS is, in general, a system of devices configured to control, monitor, and manage equipment in or around a building or building area. A BMS can include, for example, an HVAC system, a security system, a lighting system, a fire alerting system, any other system that is capable of managing building functions or devices, or any combination thereof.

[0027] The BMS that serves building 10 includes an HVAC system 100. HVAC system 100 may include a plurality of HVAC devices (e.g., heaters, chillers, air handling units, pumps, fans, thermal energy storage, etc.) configured to provide heating, cooling, ventilation, or other services for building 10. For example, HVAC system 100 is shown to include a waterside system 120 and an airside system 130. Waterside system 120 may provide a heated or chilled fluid to an air handling unit of airside system 130. Airside system 130 may use the heated or chilled fluid to heat or cool an airflow provided to building 10. In some embodiments, waterside system 120 is replaced with a central energy plant such as central plant 200, described with reference to FIG. 2.

[0028] In some embodiments, building 10 acts as a building or campus (e.g., several buildings of a hospital campus) capable of housing some or all components of HVAC system 100. While the systems and methods described herein are primarily focused on 4 operations within a typical building (e.g., building 10), they can easily be applied to various other enclosures or spaces (e.g., cars, airplanes, recreational vehicles, etc.).

[0029] Still referring to FIG. 1, HVAC system 100 is shown to include a chiller 102, a boiler 104, and a rooftop air handling unit (AHU) 106. Waterside system 120 may use boiler 104 and chiller 102 to heat or cool a working fluid (e.g., water, glycol, etc.) and may circulate the working fluid to AHU 106. In various embodiments, the HVAC devices of waterside system 120 may be located in or around building 10 (as shown in FIG. 1) or at an offsite location such as a central plant (e.g., a chiller plant, a steam plant, a heat plant, etc.). The working fluid may be heated in boiler 104 or cooled in chiller 102, depending on whether heating or cooling is required in building 10. Boiler 104 may add heat to the circulated fluid, for example, by burning a combustible material (e.g., natural gas) or using an electric heating element. Chiller 102 may place the circulated fluid in a heat exchange relationship with another fluid (e.g., a refrigerant) in a heat exchanger (e.g., an evaporator) to absorb heat from the circulated fluid. The working fluid from chiller 102 and/or boiler 104 may be transported to AHU 106 via piping 108.

[0030] AHU 106 may place the working fluid in a heat exchange relationship with an airflow passing through AHU 106 (e.g., via one or more stages of cooling coils and/or heating coils). The airflow may be, for example, outside air, return air from within building 10, or a combination of both. AHU 106 may transfer heat between the airflow and the working fluid to provide heating or cooling for the airflow. For example, AHU 106 may include one or more fans or blowers configured to pass the airflow over or through a heat exchanger containing the working fluid. The working fluid may then return to chiller 102 or boiler 104 via piping 110.

[0031] Airside system 130 may deliver the airflow supplied by AHU 106 (i.e., the supply airflow) to building 10 via air supply ducts 112 and may provide return air from building 10 to AHU 106 via air return ducts 114. In some embodiments, airside system 130 includes multiple variable air volume (VAV) units 116. For example, airside system 130 is shown to include a separate VAV unit 116 on each floor or zone of building 10. VAV units 116 may include dampers or other flow control elements that can be operated to control an amount of the supply airflow provided to individual zones of building 10. In other embodiments, airside system 130 delivers the supply airflow into one or more zones of building 10 (e.g., via air supply ducts 112) without using intermediate VAV units 116 or other flow control 5 elements. AHU 106 may include various sensors (e.g., temperature sensors, pressure sensors, etc.) configured to measure attributes of the supply airflow. AHU 106 may receive input from sensors located within AHU 106 and/or within the building zone and may adjust the flowrate, temperature, or other attributes of the supply airflow through AHU 106 to achieve setpoint conditions for the building zone.

[0032] Referring now to FIG. 2, a block diagram of a central plant 200 is shown, according to an exemplary embodiment. In brief overview, central plant 200 may include various types of equipment configured to serve the thermal energy loads of a building or campus (i.e., a system of buildings). For example, central plant 200 may include heaters, chillers, heat recovery chillers, cooling towers, or other types of equipment configured to serve the heating and/or cooling loads of a building or campus. Central plant 200 may consume resources from a utility (e.g., electricity, water, natural gas, etc.) to heat or cool a working fluid that is circulated to one or more buildings or stored for later use (e.g., in thermal energy storage tanks) to provide heating or cooling for the buildings. In various embodiments, central plant 200 may supplement or replace waterside system 120 in building 10 or may be implemented separate from building 10 (e.g., at an offsite location).

[0033] Central plant 200 is shown to include a plurality of subplants 202-212 including a heater subplant 202, a heat recovery chiller subplant 204, a chiller subplant 206, a cooling tower subplant 208, a hot thermal energy storage (TES) subplant 210, and a cold thermal energy storage (TES) subplant 212. Subplants 202-212 consume resources from utilities to serve the thermal energy loads (e.g., hot water, cold water, heating, cooling, etc.) of a building or campus. For example, heater subplant 202 may be configured to heat water in a hot water loop 214 that circulates the hot water between heater subplant 202 and building 10. Chiller subplant 206 may be configured to chill water in a cold water loop 216 that circulates the cold water between chiller subplant 206 and building 10. Heat recovery chiller subplant 204 may be configured to transfer heat from cold water loop 216 to hot water loop 214 to provide additional heating for the hot water and additional cooling for the cold water. Condenser water loop 218 may absorb heat from the cold water in chiller subplant 206 and reject the absorbed heat in cooling tower subplant 208 or transfer the absorbed heat to hot water loop 214. Hot TES subplant 210 and cold TES subplant 212 may store hot and cold thermal energy, respectively, for subsequent use. 6 [0034] Hot water loop 214 and cold water loop 216 may deliver the heated and/or chilled water to air handlers located on the rooftop of building 10 (e.g., AHU 106) or to individual floors or zones of building 10 (e.g., VAV units 116). The air handlers push air past heat exchangers (e.g., heating coils or cooling coils) through which the water flows to provide heating or cooling for the air. The heated or cooled air may be delivered to individual zones of building 10 to serve the thermal energy loads of building 10. The water then returns to subplants 202-212 to receive further heating or cooling.

[0035] Although subplants 202-212 are shown and described as heating and cooling water for circulation to a building, it is understood that any other type of working fluid (e.g., glycol, CO2, etc.) may be used in place of or in addition to water to serve the thermal energy loads. In other embodiments, subplants 202-212 may provide heating and/or cooling directly to the building or campus without requiring an intermediate heat transfer fluid. These and other variations to central plant 200 are within the teachings of the present invention.

[0036] Each of subplants 202-212 may include a variety of equipment configured to facilitate the functions of the subplant. For example, heater subplant 202 is shown to include a plurality of heating elements 220 (e.g., boilers, electric heaters, etc.) configured to add heat to the hot water in hot water loop 214. Heater subplant 202 is also shown to include several pumps 222 and 224 configured to circulate the hot water in hot water loop 214 and to control the flowrate of the hot water through individual heating elements 220. Chiller subplant 206 is shown to include a plurality of chillers 232 configured to remove heat from the cold water in cold water loop 216. Chiller subplant 206 is also shown to include several pumps 234 and 236 configured to circulate the cold water in cold water loop 216 and to control the flowrate of the cold water through individual chillers 232.

[0037] Heat recovery chiller subplant 204 is shown to include a plurality of heat recovery heat exchangers 226 (e.g., refrigeration circuits) configured to transfer heat from cold water loop 216 to hot water loop 214. Heat recovery chiller subplant 204 is also shown to include several pumps 228 and 230 configured to circulate the hot water and/or cold water through heat recovery heat exchangers 226 and to control the flowrate of the water through individual heat recovery heat exchangers 226. Cooling tower subplant 208 is shown to include a plurality of cooling towers 238 configured to remove heat from the condenser water in condenser water loop 218. Cooling tower subplant 208 is also shown to include 7 several pumps 240 configured to circulate the condenser water in condenser water loop 218 and to control the flowrate of the condenser water through individual cooling towers 238.

[0038] Hot TES subplant 210 is shown to include a hot TES tank 242 configured to store the hot water for later use. Hot TES subplant 210 may also include one or more pumps or valves configured to control the flowrate of the hot water into or out of hot TES tank 242. Cold TES subplant 212 is shown to include cold TES tanks 244 configured to store the cold water for later use. Cold TES subplant 212 may also include one or more pumps or valves configured to control the flowrate of the cold water into or out of cold TES tanks 244.

[0039] In some embodiments, one or more of the pumps in central plant 200 (e.g., pumps 222, 224, 228, 230, 234, 236, and/or 240) or pipelines in central plant 200 include an isolation valve associated therewith. Isolation valves may be integrated with the pumps or positioned upstream or downstream of the pumps to control the fluid flows in central plant 200. In various embodiments, central plant 200 may include more, fewer, or different types of devices and/or subplants based on the particular configuration of central plant 200 and the types of loads served by central plant 200.

[0040] Referring now to FIG. 3, a block diagram of an airside system 300 is shown, according to an exemplary embodiment. In various embodiments, airside system 300 can supplement or replace airside system 130 in HVAC system 100, or can be implemented separate from HVAC system 100. When implemented in HVAC system 100, airside system 300 can include a subset of the HVAC devices in HVAC system 100 (e.g., AHU 106, VAV units 116, duct 112, duct 114, fans, dampers, etc.) and can be located in or around building 10. Airside system 300 can operate to heat or cool an airflow provided to building 10 using a heated or chilled fluid provided by waterside system 200.

[0041] In FIG. 3, airside system 300 is shown to include an economizer-type air handling unit (AHU) 302. Economizer-type AHUs vary the amount of outside air and return air used by the air handling unit for heating or cooling. For example, AHU 302 can receive return air 304 from building zone 306 via return air duct 308 and can deliver supply air 310 to building zone 306 via supply air duct 312. In some embodiments, AHU 302 is a rooftop unit located on the roof of building 10 (e.g., AHU 106 as shown in FIG. 1) or otherwise positioned to receive both return air 304 and outside air 314. AHU 302 can be configured to operate exhaust air damper 316, mixing damper 318, and outside air damper 320 to 8 control an amount of outside air 314 and return air 304 that combine to form supply air 310. Any return air 304 that does not pass through mixing damper 318 can be exhausted from AHU 302 through exhaust damper 316 as exhaust air 322.

[0042] Each of dampers 316-320 can be operated by an actuator. For example, exhaust air damper 316 can be operated by actuator 324, mixing damper 318 can be operated by actuator 326, and outside air damper 320 can be operated by actuator 328. Actuators 324- 328 can communicate with an AHU controller 330 via a communications link 332. Actuators 324-328 can receive control signals from AHU controller 330 and can provide feedback signals to AHU controller 330. Feedback signals can include, for example, an indication of a current actuator or damper position, an amount of torque or force exerted by the actuator, diagnostic information (e.g., results of diagnostic tests performed by actuators 324-328), status information, commissioning information, configuration settings, calibration data, and/or other types of information or data that can be collected, stored, or used by actuators 324-328. AHU controller 330 can be an economizer controller configured to use one or more control algorithms (e.g., state-based algorithms, extremum seeking control (ESC) algorithms, proportional-integral (PI) control algorithms, proportional-integral-derivative (PID) control algorithms, model predictive control (MPC) algorithms, feedback control algorithms, etc.) to control actuators 324-328.

[0043] Still referring to FIG. 3, AHU 302 is shown to include a cooling coil 334, a heating coil 336, and a fan 338 positioned within supply air duct 312. Fan 338 can be configured to force supply air 310 through cooling coil 334 and/or heating coil 336 and provide supply air 310 to building zone 306. AHU controller 330 can communicate with fan 338 via communications link 340 to control a flowrate of supply air 310. In some embodiments, AHU controller 330 controls an amount of heating or cooling applied to supply air 310 by modulating a speed of fan 338.

[0044] Cooling coil 334 can receive a chilled fluid from waterside system 200 (e.g., from cold water loop 216) via piping 342 and can return the chilled fluid to waterside system 200 via piping 344. Valve 346 can be positioned along piping 342 or piping 344 to control a flowrate of the chilled fluid through cooling coil 334. In some embodiments, cooling coil 334 includes multiple stages of cooling coils that can be independently activated and deactivated (e.g., by AHU controller 330, by BMS controller 366, etc.) to modulate an amount of cooling applied to supply air 310. 9 [0045] Heating coil 336 can receive a heated fluid from waterside system 200 (e.g., from hot water loop 214) via piping 348 and can return the heated fluid to waterside system 200 via piping 350. Valve 352 can be positioned along piping 348 or piping 350 to control a flowrate of the heated fluid through heating coil 336. In some embodiments, heating coil 336 includes multiple stages of heating coils that can be independently activated and deactivated (e.g., by AHU controller 330, by BMS controller 366, etc.) to modulate an amount of heating applied to supply air 310.

[0046] Each of valves 346 and 352 can be controlled by an actuator. For example, valve 346 can be controlled by actuator 354 and valve 352 can be controlled by actuator 356. Actuators 354-356 can communicate with AHU controller 330 via communications links 358-360. Actuators 354-356 can receive control signals from AHU controller 330 and can provide feedback signals to controller 330. In some embodiments, AHU controller 330 receives a measurement of the supply air temperature from a temperature sensor 362 positioned in supply air duct 312 (e.g., downstream of cooling coil 334 and/or heating coil 336). AHU controller 330 can also receive a measurement of the temperature of building zone 306 from a temperature sensor 364 located in building zone 306.

[0047] In some embodiments, AHU controller 330 operates valves 346 and 352 via actuators 354-356 to modulate an amount of heating or cooling provided to supply air 310 (e.g., to achieve a setpoint temperature for supply air 310 or to maintain the temperature of supply air 310 within a setpoint temperature range). The positions of valves 346 and 352 affect the amount of heating or cooling provided to supply air 310 by cooling coil 334 or heating coil 336 and may correlate with the amount of energy consumed to achieve a desired supply air temperature. AHU controller 330 can control the temperature of supply air 310 and/or building zone 306 by activating or deactivating coils 334-336, adjusting a speed of fan 338, or a combination of both.

[0048] Still referring to FIG. 3, airside system 300 is shown to include a building management system (BMS) controller 366 and a client device 368. BMS controller 366 can include one or more computer systems (e.g., servers, supervisory controllers, subsystem controllers, etc.) that serve as system level controllers, application or data servers, head nodes, or master controllers for airside system 300, waterside system 200, HVAC system 100, and/or other controllable systems that serve building 10. BMS controller 366 can communicate with multiple downstream building systems or subsystems (e.g., HVAC 10 system 100, a security system, a lighting system, waterside system 200, etc.) via a communications link 370 according to like or disparate protocols (e.g., LON, BACnet, etc.). In various embodiments, AHU controller 330 and BMS controller 366 can be separate (as shown in FIG. 3) or integrated. In an integrated implementation, AHU controller 330 can be a software module configured for execution by a processor of BMS controller 366.

[0049] In some embodiments, AHU controller 330 receives information from BMS controller 366 (e.g., commands, setpoints, operating boundaries, etc.) and provides information to BMS controller 366 (e.g., temperature measurements, valve or actuator positions, operating statuses, diagnostics, etc.). For example, AHU controller 330 can provide BMS controller 366 with temperature measurements from temperature sensors 362 and 364, equipment on/off states, equipment operating capacities, and/or any other information that can be used by BMS controller 366 to monitor or control a variable state or condition within building zone 306.

[0050] Client device 368 can include one or more human-machine interfaces or client interfaces (e.g., graphical user interfaces, reporting interfaces, text-based computer interfaces, client-facing web services, web servers that provide pages to web clients, etc.) for controlling, viewing, or otherwise interacting with HVAC system 100, its subsystems, and/or devices. Client device 368 can be a computer workstation, a client terminal, a remote or local interface, or any other type of user interface device. Client device 368 can be a stationary terminal or a mobile device. For example, client device 368 can be a desktop computer, a computer server with a user interface, a laptop computer, a tablet, a smartphone, a PDA, or any other type of mobile or non-mobile device. Client device 368 can communicate with BMS controller 366 and/or AHU controller 330 via communications link 372.

[0051] Referring now to FIG. 4, a block diagram of a building management system (BMS) 400 is shown, according to an exemplary embodiment. BMS 400 can be implemented in building 10 to automatically monitor and control various building functions. BMS 400 is shown to include BMS controller 366 and a plurality of building subsystems 428. Building subsystems 428 are shown to include a building electrical subsystem 434, an information communication technology (ICT) subsystem 436, a security subsystem 438, an HVAC subsystem 440, a lighting subsystem 442, a lift/escalators subsystem 432, and a fire safety subsystem 430. In various embodiments, building subsystems 428 can include fewer, 11 additional, or alternative subsystems. For example, building subsystems 428 can also or alternatively include a refrigeration subsystem, an advertising or signage subsystem, a cooking subsystem, a vending subsystem, a printer or copy service subsystem, or any other type of building subsystem that uses controllable equipment and/or sensors to monitor or control building 10. In some embodiments, building subsystems 428 include waterside system 200 and/or airside system 300, as described with reference to FIGS. 2 and 3.

[0052] Each of building subsystems 428 can include any number of devices, controllers, and connections for completing its individual functions and control activities. HVAC subsystem 440 can include many of the same components as HVAC system 100, as described with reference to FIGS. 1-3. For example, HVAC subsystem 440 can include a chiller, a boiler, any number of air handling units, economizers, field controllers, supervisory controllers, actuators, temperature sensors, and other devices for controlling the temperature, humidity, airflow, or other variable conditions within building 10. Lighting subsystem 442 can include any number of light fixtures, ballasts, lighting sensors, dimmers, or other devices configured to controllably adjust the amount of light provided to a building space. Security subsystem 438 can include occupancy sensors, video surveillance cameras, digital video recorders, video processing servers, intrusion detection devices, access control devices (e.g., card access, etc.) and servers, or other security-related devices.

[0053] Still referring to FIG. 4, BMS controller 366 is shown to include a communications interface 407 and a BMS interface 409. Communications interface 407 can facilitate communications between BMS controller 366 and external applications (e.g., monitoring and reporting applications 422, enterprise control applications 426, remote systems and applications 444, applications residing on client devices 448, etc.) for allowing user control, monitoring, and adjustment to BMS controller 366 and/or subsystems 428.

Communications interface 407 can also facilitate communications between BMS controller 366 and client devices 448. BMS interface 409 can facilitate communications between BMS controller 366 and building subsystems 428 (e.g., HVAC, lighting security, lifts, power distribution, business, etc.).

[0054] Interfaces 407, 409 can be or include wired or wireless communications interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications with building subsystems 428 or other external systems or devices. In various embodiments, communications via interfaces 407, 409 can be direct 12 (e.g., local wired or wireless communications) or via a communications network 446 (e.g., a WAN, the Internet, a cellular network, etc.). For example, interfaces 407, 409 can include an Ethernet card and port for sending and receiving data via an Ethernet-based communications link or network. In another example, interfaces 407, 409 can include a Wi Fi transceiver for communicating via a wireless communications network. In another example, one or both of interfaces 407, 409 can include cellular or mobile phone communications transceivers. In one embodiment, communications interface 407 is a power line communications interface and BMS interface 409 is an Ethernet interface. In other embodiments, both communications interface 407 and BMS interface 409 are Ethernet interfaces or are the same Ethernet interface.

[0055] Still referring to FIG. 4, BMS controller 366 is shown to include a processing circuit 404 including a processor 406 and memory 408. Processing circuit 404 can be communicably connected to BMS interface 409 and/or communications interface 407 such that processing circuit 404 and the various components thereof can send and receive data via interfaces 407, 409. Processor 406 can be implemented as a general purpose processor, an application-specific integrated circuit (ASIC), one or more field-programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components.

[0056] Memory 408 (e.g., memory, memory unit, storage device, etc.) can include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. Memory 408 can be or include volatile memory or non-volatile memory. Memory 408 can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. According to an exemplary embodiment, memory 408 is communicably connected to processor 406 via processing circuit 404 and includes computer code for executing (e.g., by processing circuit 404 and/or processor 406) one or more processes described herein.

[0057] In some embodiments, BMS controller 366 is implemented within a single computer (e.g., one server, one housing, etc.). In various other embodiments BMS controller 366 can be distributed across multiple servers or computers (e.g., that can exist in 13 distributed locations). Further, while FIG. 4 shows applications 422 and 426 as existing outside of BMS controller 366, in some embodiments, applications 422 and 426 can be hosted within BMS controller 366 (e.g., within memory 408).

[0058] Still referring to FIG. 4, memory 408 is shown to include an enterprise integration layer 410, an automated measurement and validation (AM&V) layer 412, a demand response (DR) layer 414, a fault detection and diagnostics (FDD) layer 416, an integrated control layer 418, and a building subsystem integration later 420. Layers 410-420 can be configured to receive inputs from building subsystems 428 and other data sources, determine optimal control actions for building subsystems 428 based on the inputs, generate control signals based on the optimal control actions, and provide the generated control signals to building subsystems 428. The following paragraphs describe some of the general functions performed by each of layers 410-420 in BMS 400.

[0059] Enterprise integration layer 410 can be configured to serve clients or local applications with information and services to support a variety of enterprise-level applications. For example, enterprise control applications 426 can be configured to provide subsystem-spanning control to a graphical user interface (GUI) or to any number of enterprise-level business applications (e.g., accounting systems, user identification systems, etc.). Enterprise control applications 426 can also or alternatively be configured to provide configuration GUIs for configuring BMS controller 366. In yet other embodiments, enterprise control applications 426 can work with layers 410-420 to optimize building performance (e.g., efficiency, energy use, comfort, or safety) based on inputs received at communications interface 407 and/or BMS interface 409.

[0060] Building subsystem integration layer 420 can be configured to manage communications between BMS controller 366 and building subsystems 428. For example, building subsystem integration layer 420 can receive sensor data and input signals from building subsystems 428 and provide output data and control signals to building subsystems 428. Building subsystem integration layer 420 can also be configured to manage communications between building subsystems 428. Building subsystem integration layer 420 translate communications (e.g., sensor data, input signals, output signals, etc.) across a plurality of multi-vendor/multi-protocol systems. 14 [0061] Demand response layer 414 can be configured to optimize resource usage (e.g., electricity use, natural gas use, water use, etc.) and/or the monetary cost of such resource usage in response to satisfy the demand of building 10. The optimization can be based on time-of-use prices, curtailment signals, energy availability, or other data received from utility providers, distributed energy generation systems 424, from energy storage 427 (e.g., hot TES 242, cold TES 244, etc.), or from other sources. Demand response layer 414 can receive inputs from other layers of BMS controller 366 (e.g., building subsystem integration layer 420, integrated control layer 418, etc.). The inputs received from other layers can include environmental or sensor inputs such as temperature, carbon dioxide levels, relative humidity levels, air quality sensor outputs, occupancy sensor outputs, room schedules, and the like. The inputs can also include inputs such as electrical use (e.g., expressed in kWh), thermal load measurements, pricing information, projected pricing, smoothed pricing, curtailment signals from utilities, and the like.

[0062] According to an exemplary embodiment, demand response layer 414 includes control logic for responding to the data and signals it receives. These responses can include communicating with the control algorithms in integrated control layer 418, changing control strategies, changing setpoints, or activating/deactivating building equipment or subsystems in a controlled manner. Demand response layer 414 can also include control logic configured to determine when to utilize stored energy. For example, demand response layer 414 can determine to begin using energy from energy storage 427 just prior to the beginning of a peak use hour.

[0063] In some embodiments, demand response layer 414 includes a control module configured to actively initiate control actions (e.g., automatically changing setpoints) which minimize energy costs based on one or more inputs representative of or based on demand (e.g., price, a curtailment signal, a demand level, etc.). In some embodiments, demand response layer 414 uses equipment models to determine an optimal set of control actions. The equipment models can include, for example, thermodynamic models describing the inputs, outputs, and/or functions performed by various sets of building equipment. Equipment models can represent collections of building equipment (e.g., subplants, chiller arrays, etc.) or individual devices (e.g., individual chillers, heaters, pumps, etc.).

[0064] Demand response layer 414 can further include or draw upon one or more demand response policy definitions (e.g., databases, XML files, etc.). The policy definitions can be 15 edited or adjusted by a user (e.g., via a graphical user interface) so that the control actions initiated in response to demand inputs can be tailored for the user’s application, desired comfort level, particular building equipment, or based on other concerns. For example, the demand response policy definitions can specify which equipment can be turned on or off in response to particular demand inputs, how long a system or piece of equipment should be turned off, what setpoints can be changed, what the allowable set point adjustment range is, how long to hold a high demand setpoint before returning to a normally scheduled setpoint, how close to approach capacity limits, which equipment modes to utilize, the energy transfer rates (e.g., the maximum rate, an alarm rate, other rate boundary information, etc.) into and out of energy storage devices (e.g., thermal storage tanks, battery banks, etc.), and when to dispatch on-site generation of energy (e.g., via fuel cells, a motor generator set, etc.).

[0065] Integrated control layer 418 can be configured to use the data input or output of building subsystem integration layer 420 and/or demand response layer 414 to make control decisions. Due to the subsystem integration provided by building subsystem integration layer 420, integrated control layer 418 can integrate control activities of the subsystems 428 such that the subsystems 428 behave as a single integrated supersystem. In an exemplary embodiment, integrated control layer 418 includes control logic that uses inputs and outputs from a plurality of building subsystems to provide greater comfort and energy savings relative to the comfort and energy savings that separate subsystems could provide alone.

For example, integrated control layer 418 can be configured to use an input from a first subsystem to make an energy-saving control decision for a second subsystem. Results of these decisions can be communicated back to building subsystem integration layer 420.

[0066] Integrated control layer 418 is shown to be logically below demand response layer 414. Integrated control layer 418 can be configured to enhance the effectiveness of demand response layer 414 by enabling building subsystems 428 and their respective control loops to be controlled in coordination with demand response layer 414. This configuration may advantageously reduce disruptive demand response behavior relative to conventional systems. For example, integrated control layer 418 can be configured to assure that a demand response-driven upward adjustment to the setpoint for chilled water temperature (or another component that directly or indirectly affects temperature) does not result in an 16 increase in fan energy (or other energy used to cool a space) that would result in greater total building energy use than was saved at the chiller.

[0067] Integrated control layer 418 can be configured to provide feedback to demand response layer 414 so that demand response layer 414 checks that constraints (e.g., temperature, lighting levels, etc.) are properly maintained even while demanded load shedding is in progress. The constraints can also include setpoint or sensed boundaries relating to safety, equipment operating limits and performance, comfort, fire codes, electrical codes, energy codes, and the like. Integrated control layer 418 is also logically below fault detection and diagnostics layer 416 and automated measurement and validation layer 412. Integrated control layer 418 can be configured to provide calculated inputs (e.g., aggregations) to these higher levels based on outputs from more than one building subsystem.

[0068] Automated measurement and validation (AM&V) layer 412 can be configured to verify that control strategies commanded by integrated control layer 418 or demand response layer 414 are working properly (e.g., using data aggregated by AM&V layer 412, integrated control layer 418, building subsystem integration layer 420, FDD layer 416, or otherwise). The calculations made by AM&V layer 412 can be based on building system energy models and/or equipment models for individual BMS devices or subsystems. For example, AM&V layer 412 can compare a model -predicted output with an actual output from building subsystems 428 to determine an accuracy of the model.

[0069] Fault detection and diagnostics (FDD) layer 416 can be configured to provide ongoing fault detection for building subsystems 428, building subsystem devices (i.e., building equipment), and control algorithms used by demand response layer 414 and integrated control layer 418. FDD layer 416 can receive data inputs from integrated control layer 418, directly from one or more building subsystems or devices, or from another data source. FDD layer 416 can automatically diagnose and respond to detected faults. The responses to detected or diagnosed faults can include providing an alert message to a user, a maintenance scheduling system, or a control algorithm configured to attempt to repair the fault or to work around the fault.

[0070] FDD layer 416 can be configured to output a specific identification of the faulty component or cause of the fault (e.g., loose damper linkage) using detailed subsystem inputs 17 available at building subsystem integration layer 420. In other exemplary embodiments, FDD layer 416 is configured to provide “fault” events to integrated control layer 418 which executes control strategies and policies in response to the received fault events. According to an exemplary embodiment, FDD layer 416 (or a policy executed by an integrated control engine or business rules engine) can shut down systems or direct control activities around faulty devices or systems to reduce energy waste, extend equipment life, or assure proper control response.

[0071] FDD layer 416 can be configured to store or access a variety of different system data stores (or data points for live data). FDD layer 416 can use some content of the data stores to identify faults at the equipment level (e.g., specific chiller, specific AHU, specific terminal unit, etc.) and other content to identify faults at component or subsystem levels. For example, building subsystems 428 can generate temporal (i.e., time-series) data indicating the performance of BMS 400 and the various components thereof. The data generated by building subsystems 428 can include measured or calculated values that exhibit statistical characteristics and provide information about how the corresponding system or process (e.g., a temperature control process, a flow control process, etc.) is performing in terms of error from its setpoint. These processes can be examined by FDD layer 416 to expose when the system begins to degrade in performance and alert a user to repair the fault before it becomes more severe.

Integrated Command Center

[0072] Referring now to FIG. 5, a block diagram of supersystem 500 is shown, according to some embodiments. The supersystem 500 may be integrated with any of the systems described herein, such as the HVAC system 100, the waterside system 200, the airside system 300, and the BMS system 400. The supersystem 500 is shown to include multiple systems that are affiliated with the building 10, and a command center engineer for aggregating and analyzing data from the one or more systems. The supersystem 500 is shown to include the BMS 400, a registration system 512, a scheduling system 514, an electronic medical records (EMR) system 516, a laboratory monitoring system 518, a physiological monitoring system 520, a bed management system 522, a real time location system 524, a caregiver monitoring system 526, transport system 528, an environmental services (EVS) 530, a medical appointment scheduling (MAS) system 532, a patient preference management system (PPMS) 534, and an event correlation engine 536. 18 Additionally, the supersystem 500 is shown to include a command center engine 502 including an interface manager 504, an analytics manager 506, and a reporting manager 508.

[0073] The registration system 512 may be configured to facilitate registration with the building 10. In some embodiments, a user registers for their appointment at the building 10 via an application. In some embodiments, the application provides global positioning satellite (GPS) coordinates to a user prior to and/or during the commute to building 10. The application may provide directions to the user that may include color coding and/or sound indicators. For example, on the application the user may be represented as a blue dot following a green path towards the building 10. Once inside the building 10, the application may also provide directions to the particular room or other location required to complete registration. In some embodiments, the application includes GPS instructions and assistance for several aspects of a visit to the building 10, such as providing guidance to another wing of building 10, providing guidance to a bathroom, and providing guidance to a new location to continue the visit at the building 10. In some embodiments, the MAS system 532 is included in the registration system 512, and is configured to facilitate medical appointment scheduling and coordinate travel to the appointment in a timely manner. Integration of the scheduling, check in, and navigation improves the user’s ability to schedule and travel to appointments and allows for a more accurate schedule for the facility.

[0074] The scheduling system 514 may be configured to facilitate improved scheduling of the patients using the collected data at the command center engine 502. In some embodiments, the scheduling system 514 receives user preferences from the registration system 512 and uses that information to selectively schedule the time/date for the appointment of the patient. For example, during registration, the user is prompted (e.g., via an application, etc.) with questions regarding their preferences, such as preferred times to schedule an appointment. After completing registration, the user attempts to schedule a time or data that is outside of their preferred time slots (e.g., the user prefers morning slots and the user is attempting to schedule an appointment for the afternoon, etc.), the application may respond by suggestion to the user a preferred time slot. For example, the application responds with: “Thank you for booking! We’ve noticed that you prefer time slots in the mornings for your hospital appointments. Here are some suggested time slots that fit within your preferences, in case you would like to switch.” The application may 19 then provide one or more time slots on one or more days that fits within the preferences of the user.

[0075] In some embodiments, the scheduling system 514 facilitates scheduling of one or more patients based on several sets of aggregated data, not just the data from the registration system 512. For example, the BMS 400 may determine that one or more chillers configured to supply chilled fluid to a subsystem that cools the air in a particular zone of the building 10 is inoperable and, as such, the temperature cannot be properly controlled in that building zone. The command center engine 502 receives this information and the scheduling information from the scheduling system 514, which indicates a preferred appointment in that building zone. The application (e.g., which may be communicably connected to the command center engine, or query data from the command center engine 502, etc.) may respond to the requested scheduling by notifying the user that the building cannot presently receive scheduling appointments for that location of the building. In some embodiments, the operations of the one or more systems described within the supersystem 500 utilize data sets from one or more other systems within the supersystem 500.

[0076] The EMR system 516 may be configured to update and organize electronic medical records. In some embodiments, the updating and organizing of medical records is at least in part monitored by the command center engine 502. The command center engine 502 may be configured to receive information that helps facilitate the organizing of the medical records in a more efficient manner, using aggregated data from the other systems within the supersystem 500. For example, the command center engine may include scheduling preferences (e.g., preferred scheduled times, etc.), received from the scheduling system 514, caregiver preferences (e.g., gender, qualifications, etc.) (e.g., from the caregiver monitoring system 526, etc.), bed management information (e.g., preferred room type, etc.), and other information.

[0077] The laboratory monitoring system 518 may be configured to monitor and record laboratory operations before, during, or after laboratory sessions (e.g., surgeries, scans, etc.). In some embodiments, control signals provided to the laboratory rooms are adjusted based on decisions made by the command center engine 502. For example, the command center engine 502 receives information regarding user preferences to temperature, pressure, and humidity (TPH) levels within a room from the PPMS 534. The command center engine 502 also receives information on how the TPH levels in a laboratory are to comply with 20 rules and regulations. The command center engine 502 then complies with the user preferences insomuch that they are in compliance with the rules and regulations of operation for the laboratory. Preferences of other users may also be considered, such as the doctor’s preferences or the nurse’s preferences.

[0078] The physiological monitoring system 520 may be configured to obtain real-time and/or historical data relating to the physiological operation of one or more patients. In some embodiments, the physiological monitoring system 520 provides the physiological information to the command center engine 502, such that the command center engine 502 can make decisions based on the physiological information. For example, the command center engine 502 may receive EMR’s from the EMR system 516 and the physiological data of the same patient from the physiological monitoring system 520 and determine that the physiological data is significantly abnormal compared to the EMR’s of the patient. The command center engine 502 may automatically provide a notification to the care team (e.g., the doctor, the nurse, etc.) that provides a warning related to the discovered information.

[0079] The bed management system 522 may be configured to facilitate appropriate bed management for the patients. In some embodiments, this can include assigning particular beds/rooms to patients based on their preferences (e.g., as determined by the PPMS 534). For example, a patient may prefer to be assigned to a bed with certain features (e.g., inclined back rest, additional pillows, queen-sized, etc.), which can be provided via the registration system 512. The command center engine 502 may analyze the registration preferences and assign the beds to the patients to satisfy the preferences. Of course, multiple types of preferences and/or data sets can be considered for making decisions in the physiological monitoring system 520, or any of the systems in supersystem 500.

[0080] Real time location system (RTLS) 524 may be configured to provide real-time monitoring of the one of more patients arriving at the building 10, the occupants currently within the building 10, or a combination thereof. The RTLS 524 can provide directions to users after they are within a certain distance of the building 10. For example, after crossing a geo-fence (e.g., 1 mile from the building 10, 5 miles from the building 10, etc.), an application hosted on a user’s device and communicably connected to the command center engine 502 updates the user on the directions for parking at the building 10, and continues to provide directions all the way to the appropriate room in the building 10, including providing directions while within the building 10. In some embodiments, the RTLS 524 21 tracks users (e.g., patients, building occupants, etc.) via GPS or via radio-frequency identification (RFID) from WiFi signals, Bluetooth^® signals, etc. For example, each occupant of a building may carry a device capable of RFID transmissions, such as a mobile phone, a badge or lanyard, a wristband, etc., which can be tracked by RFID transceivers positioned throughout the building. In some embodiments, the RTLS 524 utilizes facial and/or voice recognition to detect and track occupants.

[0081] The caregiver monitoring system 526 may be configured to provide updates to the care team of the patient using aggregated data within command center engine 502. For example, as described in greater detail below with reference to FIG. 7 and FIG. 12, updates can be sent to the care team (e.g., doctors, nurses, etc.) for the patient that can preemptively detect unsafe or dangerous situations, using sensor data from the patient’s room, medical records from the patients file (e.g., via EMR system 516, etc.), a profile generated by the command center engine 502 with historical data relating to the physiological information and comfort information, or any combination thereof.

[0082] The transport system 528 may be configured to facilitate transport of patients from the entrance of building 10 to the required room within building 10, or between multiple rooms within building 10. For example, an ambulance may arrive with a patient and automatically provide the command center engine 502 with an indication that the patient has arrived. The command center engine 502 may then query a database (e.g., maintained by the PPMS 534, as described below) that indicates one or more preferences for the user, such as preferred temperature, pressure, and humidity levels in the room. Thus, the room may be prepared for the patient prior to the patient arriving at the room.

[0083] The EVS system 530 may be configured to facilitate the cleaning and sanitizing of rooms, hallways, tables, and other components of building 10 (e.g., a hospital). The EVS system 530 may employ global positioning satellite (GPS) tracking of the custodians and maintain a virtual cleaning log to display locations that have been cleaned and have yet to be cleaned. In some embodiments, the EVS system 530 is particularly equipped to handle sanitization after a detection of a contagious disease (e.g., COVID-19). For example, once COVID-19 has been detected in the facility, contact tracing may be determined based on cameras located within the building 10. The command center engine 502 may receive the video feeds from the cameras and the location of the potentially contagious area, determine 22 the profiles of the potential carriers of the disease, and implement contact tracing/ preventi on .

[0084] The PPMS 534 is configured to determine, record, store, and/or retrieve various patient preferences. Patient preferences may include, for example, preferred temperature, pressure, and humidity levels in a room (e.g., a patient room), preferred lighting temperatures and intensities, preferred meal times, favorite movies or television shows, favorite musicians and bands, a patient’s sleep schedule, etc., along with any of the other patient or user preferences described herein. In some embodiments, patient preferences are entered manually, such as by a patient or facility (e.g., hospital) staff when the patient is checking-in or registering. In some embodiments, the PPMS 534 is configured to automatically determine patient preferences by recording room and/or schedule parameters over time (e.g., temperature, pressure, and humidity levels in the patient’s room) and/or by analyzing the patient’s social media accounts, bank and/or credit card purchases, search history, etc. For example, the PPMS 534 may receive preference information for a patient from a remote and/or third-party (e.g., Google^®, Facebook^®, etc.). In some embodiments, the PPMS 534 may interface with EMR system 516 to determine patient preferences and/or to store patient preferences. In some embodiments, the PPMS 534 maintains patient profiles for recording patient preferences over time. For example, patient Additional features of the PPMS 534 are described in greater detail below.

[0085] The event correlation engine 536 may be configured to monitor and detect patterns in patient care. For example, the event correlation engine 536 may monitor patient temperature checks over time, to determine an interval (i.e., frequency) between temperature checks. If a period of time (e.g., a time interval) passes without a temperature check, when one was expected, the event correlation engine 536 may transmit a notification to a care provider or other user to initiate a temperature check. In some embodiments, the event correlation engine 536 can identify correlations between building events (e.g., BMS 400 events) and clinical events. For example, the event correlation engine 536 may identify a correlation between the TPH of a patient room and patient recovery times or patient comfort.

Command Center Engine 23 [0086] Referring now to FIG. 6, a detailed block diagram of the command center engine 502 is shown, according to some embodiments. The command center engine 502 is shown to include a processing circuit 604 including a processor 606 and a memory 608 and a communications interface 650. The processing circuit 604 can be communicably connected to the communications interface 650 such that the processing circuit 604 and the various components thereof can send and receive data via the communications interface 650. The processor 606 can be implemented as a general purpose processor, an application-specific integrated circuit (ASIC), one or more field-programmable gate arrays (FPGAs), a group of processing components, or other suitable electronic processing components.

[0087] The memory 608 (e.g., memory, memory unit, storage device, etc.) can include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present application. The memory 608 can be or include volatile memory or non-volatile memory. The memory 608 can include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present application. According to an exemplary embodiment, the memory 608 is communicably connected to the processor 606 via the processing circuit 604 and includes computer code for executing (e.g., by the processing circuit 604 and/or the processor 606) one or more processes described herein. In some embodiments, the command center engine 502 is implemented within a single computer (e.g., one server, one housing, etc.). In various other embodiments the command center engine 502 can be distributed across multiple servers or computers (e.g., that can exist in distributed locations).

[0088] The communications interface 650 can facilitate communications between the command center engine 502 and other systems within supersystem 500 (e.g., the scheduling system 514, the bed management system 522, etc.) for allowing user control, monitoring, and adjustment to the command center engine 502 and/or the one or more systems in the supersystem 500. The communications interface 650 can be or include wired or wireless communications interfaces (e.g., jacks, antennas, transmitters, receivers, transceivers, wire terminals, etc.) for conducting data communications within the supersystem 500 or other external systems or devices. In various embodiments, communications via the communications interface 650 can be direct (e.g., local wired or wireless communications) 24 or via a communications network (e.g., a WAN, the Internet, a cellular network, etc.). For example, the communications interface 650 can include an Ethernet card and port for sending and receiving data via an Ethernet-based communications link or network. In another example, the communications interface 650 can include a Wi-Fi transceiver for communicating via a wireless communications network.

[0089] Memory 608 is shown to include clinical command center 610, including enterprise capacity optimization 614, critical care outreach 616, hospital operations 618, predictive analysis 620, care communication 622, early warning surveillance 624, pandemic management 626, and virtual care 628. The memory 608 is also shown to include facility command center 612, including building automation 630, fire systems 632, nurse call system 634, telecom operators 636, asset management 638, medical gas management 640, automated guided vehicles 642, and security 644. The memory 608 is shown to further include integrated command center 646.

Command Center Engine Processes

Early Warning System

[0090] Referring now to FIG. 6, a system 700 of command center engine 502 with early warning system functionality is shown, according to some embodiments. System 700 is shown to include the command center engine 502, HVAC equipment 712, a notification system 714, a care team hub 716, and a patient room 718. In some embodiments, system 700 is configured to provide early warnings to the care team hub 716 or directly to occupants within building 10 (e.g., via the notification system 714, etc.). This may be performed using data collected from sensors within the patient room 718. The early warning system and methods described with reference to FIG. 7 may be or be included in one or more of the systems of the supersystem 500, such as the BMS 400.

[0091] In some embodiments, the sensors 720 may obtain information related to any type of manipulated or control variable within system 700. For example, the sensors 720 obtain measurements on the temperature, pressure, humidity, light intensity, blinds position, sound level, motion, or a combination thereof, and provides the sensor data to the data collector 702 in the command center engine 502. The data collector 702 may be configured to provide the sate-data of the patient room to the neural network 706. 25 [0092] The neural network 706 may be configured to make predictions regarding certain situations that may warrant the distribution of a notification, warning, or alarm for safety reasons. Accordingly, the neural network 706 may be any suitable type of neural network, such as a perceptron, feed forward, recurrent (R N), deep feed forward, convolutional, residual, support vector machine (SVM), etc. In some embodiments, however, the neural network 706 may be replaced with other model or algorithm-based prediction methods (e.g., clustering, forecast, time series, etc.). While not shown, the neural network 706 may be trained using historical data. For example, the neural network may use data regarding the patient room 718, data regarding the patients that have previously been in the patient room 718, and/or metadata regarding all patients and patient rooms, to generate a model of “safe” conditions. As shown, the neural network 706 may be configured to output optimal TPH settings or levels for an area (e.g., a patient room) based on patient metadata.

[0093] For example, a 20 year old male is put in the patient room 718 for a back injury. The neural network 706 uses training data including several months of different patients that have been placed in the patient room 718, historical data on 20 year old males, and patients with back injuries over a historical time period. In some embodiments, the neural network 706 attempts to satisfy an objective function, wherein the goal of the objective function is to provide the appropriate sensor value (e.g., temperature) based on the number of factors. In the above example, the historical data indicating the temperature preference of 20 year old males may be weighted differently than the temperature preference of a patient with back injuries, which may be weighted differently that patients located in the patient room 718. This can result in a multi -weighted objective function, which can also include one or more constraints. In some embodiments, the constraints are provided to make sure that the manipulated variable conforms to general rules and regulations. For example, if the objective function indicated that the temperature should be 100°F, a constraint may forbid a control signal attempting to reach a 100°F setpoint in the patient room 718, the constraint not allowing temperature setpoints above 75°F.

[0094] In some embodiments, the neural network 706 is shown to receive metadata of all patients, including the data of the patient located in the patient room 718. This data could include previously preferred manipulated variables (e.g., temperature, pressure, humidity, light intensity, sound level, etc.), setpoints from the patient, medical data related to the patient, of the data for any and all patients that have logged data with the command center 26 engine 502. For example, the neural network 706 may receive data from one or more sensors or devices monitoring the vitals and other physiological parameters of the patient. The neural network 706 may be configured to adjust TPH values in the room based on the patient’s vitals (e.g., cooling the room to lower the patient’s core temperature).

[0095] In some embodiments, the neural network 706 also receives patient data indicating classification or diagnostic codes for the patient. These codes can include International Statistical Classification of Diseases and Related Health Problems (ICD) codes, Diagnosis- Related Group (DRG) codes, Current Procedural Terminology (CPT) codes, and/or any other similar type of classification or diagnostic code format that may be implemented by a healthcare facility. In some such embodiments, the neural network 706 includes these types of codes (e.g., as an input) when determining TPH values or other parameters for the patient’s room. For example, a patient experiencing COVID-19 symptoms can be assigned IDC code “U07.1, 2019-nCoV acute respiratory disease” and, in response, the TPH or other parameters of the patient’s room may be adjusted to not only improve patient care, but to help prevent or slow the spread of COVID-19 to other patients and/or areas within the building. In this example, the patient’s room may be isolated from other areas of a hospital, such as by adjusting HVAC equipment and/or by changing TPH values of the room. In another example, a sleep protocol may be initiated in response to particular classification or diagnostic codes and may cause the lights in the patient’s room to dim, the blinds to close, the temperature to lower, etc.

[0096] In some embodiments, any of the data discussed above may also be used to train the neural network 706. After training, the neural network 706 may then be used to satisfy an objective function. Once the neural network 706 implemented and a predicted manipulated variable value is determined by the neural network 706, the TPH manager 708 may generate control signals via the control signal generator 710 to satisfy the predicted manipulated variable value. In some embodiments, this includes setting the manipulated variable value as a setpoint and providing control signals to the HVAC equipment 712 to satisfy the setpoint.

[0097] As mentioned above, the command center engine 502 may be configured to provide early warning detection based on received data. As such, the trained neural network 706 may be able to determine if the manipulated variable(s) are abnormal such that they indicate an unsafe environment in the patient room 718. In such embodiments, the 27 control signal generator 710 may provide notifications to the care team hub to help the patient. While not shown, the control signal generator 710 may also provide a control signals to the HVAC equipment to adjust the manipulated variable to a safe level. In some embodiments, early warning detection is based in part of the number, type, and/or frequency of patient temperature change requests (e.g., from an application for adjusting parameters of the patient room).

[0098] In some embodiments, the control signal generator 710 can provide warning notifications to the notification system 714. The notification system 714 may be a system communicably connected to workstations within building 10, one or more user devices of the occupants within building 10 (e.g., or will eventually be within building 10), or any combination thereof. For example, the control signal generator 710 provides a warning indicated that the temperature within the patient room 718 is too high for the patient, who is particularly sensitive to high temperatures. A building manager receives the notification and supervises the adjustment of the temperature setpoint down to a safe level.

[0099] In some embodiments, command center engine 502 may know the room TPH values and how most people should feel within the room (e.g., based on neural network functionality described above, etc.). For example, if a patient requests a temperature change in the room, command center engine 502 may then use demographic information (e.g., height, weight, gender, medical history, etc.) to determine if the care team needs to be alerted, or if it is merely a preferential temperature change.

[0100] Command center engine 502 may be configured to integrate any and all systems within supersystem 500. In some embodiments, supersystem 500 is configured to improve noise levels for patients in their rooms, improve energy efficiency within BMS 400, improve sleep quality for patients, reduce infection risk, increase care team response times (e.g., notifying the closest nurse and not necessarily the assigned nurse, etc.), and increase security response time.

Service Rerouting

[0101] The integration provided by the command center engine 502 allows the system to provide improved service and facility efficiency. In some embodiments, if a service (e.g., an MRI machine, a vaccination, etc.) is backed up or is experiencing longer than usual wait times at one location (e.g. building 10, etc.), command center engine 502 can provide a 28 notification to the user and provide an option to receive service at an alternative location in network, such as at a hospital at another location. The recommendation of an alternate location can include a prompt to accept or reject the recommended alternate location. In some embodiments, the command center engine 502 utilizes an algorithm based on travel times from a user’s current location to the available buildings and the wait times at the available buildings and recommends the shortest total time to service. For example, a 90 minute wait may exist at the scheduled location, but a location 3 miles away may have immediate availability. The selection of an alternate location can reduce the time it takes the user to receive service and also improves the efficiency of each building. For example, a building with long wait times may experience a crowded waiting room and irritated patients.

[0102] In some embodiments, the command center engine 502 also considers a type of care required for the patient. In some such embodiments, the type of care required for the patient can be determined based on classification or diagnostic codes, such as the ICD, DRG, and/or CPT codes discussed above. For example, the command center engine 502 may identify only those alternate locations that are capable of treating a patient associated with specific classification or diagnostic codes. In some embodiments, a determination that a location is suitable for treating a patient is made based on the equipment, staffing, and/or capabilities of the location. For example, a location without an MRI machine may not be suitable to treat a patient that is classified as having a head injury. As another example, a location that does not staff pediatric physicians may be less suitable for a patient under 10 years old than a location that does staff pediatric physicians.

[0103] In some embodiments, the command center engine 502 is configured to rank and/or score facilities based on the patient’s required type of care (e.g., based on ICD, DRG, and/or CPT codes). In some such embodiments, the command center engine 502 may calculate and assign a rating (e.g., on a scale from zero to five, based on a number of stars, as a percentage, etc.) for each identified alternate location, which could be presented to a patient when recommending alternate locations. For example, a patient may be presented with an interface that lists a plurality of potential alternate locations, a wait time and/or distance for each alternate location, and a star-rating for each location. Accordingly, in this example, the patient can weigh whether a longer wait time at a first, five-star rated location would be preferable over a shorter wait time at a second, four-star rated location. 29 [0104] The ability to recommend alternate locations has the effect of spreading the patient load between facilities and reducing the number of individuals positioned in waiting rooms. The reduction of individuals in waiting rooms provides a number of benefits including the reduced likelihood of transmission of illness. The command center engine 502 can coordinate scheduling changes and navigation changes when a user selects or accepts an alternate location. Coordination of scheduling includes reserving appointment slots, adjusting doctor or caregiver schedules, coordinating room allocation and parameter control, etc. Alternatively, the command center engine 502 can maintain the currently selected location if the user rejects the recommendation (e.g., the user may wish to go to a building with a longer wait time if the building is also convenient for other reasons such as visiting a friend or running errands nearby).

Integrated Parking Control

[0105] Referring now to FIG. 8, a system 800 showing a command center engine with integrated parking control is shown, according to some embodiments. System 800 may be configured to facilitate parking for a building occupant of the building 10 leaving the building 10, or an occupant arriving at the building 10. The command center engine 502 can include functionality that receives the occupant’s location and other data (e.g., prescription data from the EMR system 516, etc.) and creates a more streamlined and efficient parking situation for the occupant. The command center engine 502 is shown to include a parking preference manager 802, a parking spots database 804, a payments manager 806, a parking manager 808, a GPS manager 810, a parking lights manager 812, and a valet notification manager 814.

[0106] In some embodiments, an occupant arrives at a parking structure of the building 10. Either prior to arriving or after arriving at the parking structure, the user, using a user device 818, provides preferred parking criteria, such as proximity to the entrance of the building 10, handicapped parking, requested valet services. The parking preference manager 802 receives this information and available parking information from parking spots database 804 and provides one or more available parking spots to parking manager 808 that satisfy the user’s preferences. If there are no spots that satisfy the user’s preferences that are available, the parking preference manager 802 may provide acceptable parking spots to the parking manager based on another criteria (e.g., closest to the building 10, etc.). 30 [0107] The parking manager 808 may be configured to receive the user location from GPS manager 810 and the acceptable parking spots from the parking preference manager 802 and determine a selected parking spot for the user. The parking manager 808 may also be able to determine when the user is close to arriving or has arrived at the parking spot. In some embodiments, the parking manager 808 determines that the user is close to, or at, a parking structure based on GPS data from the user’s device or vehicle, or based on a license plate recognition (LPR) system that detects the user’s vehicle (e.g., using cameras positioned at an entrance to a parking structure).

[0108] In the event that the user has requested valet services, the parking manager 808 may send a notification to the valet notification manager 814 when the occupant is close (e.g., 1 mile, 1000m, 100m, etc.) to the parking structure, indicating that the valet services should be ready to assist. In the event that the user has not requested valet services when arriving, the parking manager 808 may send a signal to parking lights manager 812 to illuminate the parking spot for the occupant. In some embodiments, the illumination is a particular color that the user is told is for them via the application 816. In some embodiments, the GPS manager 810 provides directions directly to the appropriate spot choses by the parking manager 808 for the occupant, the directions provided on the application 816.

[0109] In some embodiments, the parking manager 808 may be configured to send information directly to the application 816, such as the chosen parking spot, the parking spot location (e.g., 2^nd floor, row A, etc.) and directions to the parking spot. In some embodiments, the occupant has indicated via the application 816 that the vehicle is a self driving vehicle. In such embodiments, when the occupant has reached a reasonable proximity to the parking spot (e.g., entering the parking structure, getting near the building, etc.), the command center engine 502 may take partial or full control of the vehicle to guide the occupant’s vehicle to the chosen parking spot. In some embodiments, the parking manager 808 interfaces with a remote and/or third-party lighting system installed in the parking structure and can utilize the lighting system to guide the user to a parking spot or to identify an available parking spot. For example, a parking structure lighting system may include one or more lights (e.g., a set of lights above each parking spot), in some cases of varying or variable colors, that can indicate whether a parking spot is available, reserved, or currently occupied. The user may receive a notification (e.g., a text message, a push 31 notification, etc.) instructing the user to “follow the lights” through the parking structure to a reserved and/or available spot. In some embodiments, the parking manager 808 tracks the user’s movement through the parking structure (e.g., via the LPR system) and activates lights along the user’s path to guide the user to a parking spot. In some embodiments, the parking manager 808 is also configured to transmit a notification to the staff of a facility (e.g., hospital staff) when a user (e.g., a patient) arrives at a parking structure and/or parks their vehicle.

[0110] In some embodiments, the command center engine 502 may be aware of payments that the occupant still has to make, apart from the payment of the parking spot. For example, the occupant may need to pay for a prescription after completing an appointment. The payments manager 806 can accordingly receive information from a variety of remote and/or third-party systems, such as a pharmacy management system (not shown), and can facilitate payment to these remote and/or third-party systems at the same time as a payment for a parking spot. For example, the payments manager 806 can provide a combined transaction request to the user device 818 via the application 816 allowing the user to pay for the several transactions at once. In some embodiments, the command center engine 502 can also transmit a notification to valet staff (e.g., via valet notification manager 814) instructing the valet staff to pick up a user’s prescriptions while the user is checking-out from an appointment, or when the user is ready to leave (e.g., when the user requests their vehicle from the valet). In this manner, the user may save time by receiving their prescriptions from the valet at the same time that they retrieve their vehicle, rather than making a separate trip to a pharmacy.

Distributed Care

[0111] Referring now to FIG. 9, a system 900 with a command center engine with distributed care functionality is shown, according to some embodiments. System 900 may include some or all of the systems described herein. In some embodiments, the building 10 acts as a hive that has partial or full management control of one or more drone buildings (i.e., drone building A through drone building N). Management control of the drone buildings may include controlling their BMS systems or other systems described herein, such as those described above with reference to FIG. 5. 32 [0112] The building 10 is shown to include a command center engine 502 and a virtual command center 902. The virtual command center 902 may be configured to control at least a portion of one or more of the drone buildings. In some embodiments, the virtual command center 902 controls a single patient room (e.g., a surgical room), that can be better managed by the intelligence (e.g., processing circuitry, processing power, memory space, etc.) at the building 10 than the intelligence at the respective drone building. The building 10 is shown to receive data from the drone buildings via network 446. In some embodiments, this data includes real-time operation of the control zone, historical data of the control zone, system and subsystem layouts, or a combination thereof.

[0113] For example, the drone building A provides temperature, pressure, and humidity data to the building 10 for a surgical room at drone building A. The virtual command center 902 receives this data and, in response to at least one of a user preference, optimization, or regulatory conditions, the virtual command center 902 provides control signals to the HVAC equipment in the drone building A to satisfy the intended requests of the virtual command center 902.

[0114] In some embodiments, the virtual command center 902 of the building 10 can control rooms of the drone building A to provide functionality that is different from the functionality originally provided by the rooms of the drone building A. For example, general patient rooms of the drone building A may be controlled by the virtual command center 902 to provide TPH and other parameters that are conducive for use the general patient rooms for surgery, infection disease control, or another specific use room. The ability to remotely control rooms of the drone building A allows for an expanded flexibility and use of the drone building A while taking advantage of the more robust intelligence of building 10. In some embodiments, the virtual command center 902 can implement room uses for the drone building A that are outside the original design of the drone building A.

For example, the virtual command center 902 may receive historical sensor information from the drone building A and recognize (e.g., using a machine learning or neural network system) how to control TPH and/or other parameters to provide an overall atmosphere that is appropriate for a desired procedure or use of the drone building A.

[0115] In some embodiments, virtual command center 902 of building 10 can control a basic care control room in drone building A to provide required assistance. For example, virtual command center 902 can provide a negative pressure to allow emergency care that 33 the remote clinic was not designed for initially. Additionally, the virtual command center 902 can facilitate communication between doctors of the building 10 and the drone building A to improve the available resources and expertise available for procedures within the drone building A. For example, an emergency surgery in drone building A can include control of room parameters by the virtual command center 902 of the building 10 and a specialized doctor at building 10 can provide guidance to a doctor conducting the emergency surgery at the drone building A. The virtual command center 902 can facilitate the communication by analyzing schedules of doctors at the building 10 or another building and identify an appropriate expert and add the emergency schedule or other procedure to the expert’s schedule and provide a communication platform for connecting the two remotely located doctors.

Sentient Patient Room

[0116] Referring now to FIG. 10, a system 1000 with a command center engine with patient room functionality is shown, according to some embodiments. System 1000 is shown to include the command center engine 502 and a patient room 1002. The command center engine 502 may be configured to control the room such that “the room” (e.g., the command center engine 502) preemptively know information about the patient prior to or during the patients arrival at the patient room 1002. The command center engine 502 is shown to include a data collector 1016, a control signal generator 1018, a dashboard 1020, a comfortability manager 1022, and the user profiles 704. The patient room 1002 is shown to include a room camera(s) 1004, an entertainment system 1006, and room settings 1008. Room camera(s) 1004 may be configured to provide a video stream to the dashboard 1020, such that one or more members of the patient’s care team may view the video feed to determine how the patient is acting and if the patient requires help.

[0117] In some embodiments, the patient room 1002 provides sensor data for one or more manipulated variables to the data collector 1016. The data collector 1016 may also receive patient preferences from the user profiles 704. The data collector may then send this information to the control signal generator, so that the control signal generator 1018 can provide comfort to the patient without having the patient request the adjustments to the manipulated variable. In some embodiments, this information is combined with the processed digital video feed to determine when the patient has arrived in the patient room 1002. In some embodiments (not shown), the command center engine 502 can perform 34 facial recognition to determine which person (i.e., the patient) has arrived in the patient room 1002, and provide comfortability adjustments for the patient. In other embodiments, the command center engine 502 can determine that a person has arrived in the patient room 1002 based on RTLS data (e.g., from an RTLS enabled badge or wristband carried by a patient, physician, etc.). Other reasons for adjusting the manipulated variables can be considered too, just as the command center engine 502 determining that the patient has re entered the room, and sending a voice command to the patient, such as “Welcome back, [Name] We’ve adjusted the room to your liking. Please feel free to change any settings via the application.”

[0118] The system 1000 is structured to recognize using the sensor arrays and the video feeds the patient’s needs without input. The system 1000 is also integrated with the scheduling system so that procedures and appointments are recognized by the system 1000 and integrated into the care provided by the sentient patient room. For example, the system 1000 may utilize historical demographic information to predict a base profile policy for the patient (e.g., the average individual matching the age, gender, nationality, etc. of the patient defines a base profile of preferences), receives inputs and preferences from the patient before a stay in the sentient patient room (e.g., favorite sports team, favorite color, pictures from a past vacation, favorite authors, normal sleep temperature, favorite scents, etc.) that allow the system 1000 to update the base profile policy to provide a customized profile policy in view of patient inputs, and continue to update the customized profile policy using machine learning or artificial intelligence (e.g. neural networks, reinforcement learning, etc.) to improve a response of the sentient patient room by the system 1000 to the patients activities and actions. For example, the system 1000 may receive feedback from the patient about actions implemented by the system 1000 (e.g., thumbs up or thumbs down in response to an implemented change).

[0119] The system 1000 receives input form the scheduling system to understand why the patient is residing in the sentient patient room (e.g., a surgery and recovery are scheduled, etc.), and automatically responds to scheduled activities and patient actions to provide care. For example, the system 1000 coordinates cleaning and sanitization activities to align with times the patient will be out of the room, adjusts temperatures before a patient arrives to the room and after a patient leaves, changes meal timing based on schedules and patient reactions (e.g., if a patient is sleeping soundly, no meals are provided to wake them), adjust 35 lighting in the room (e.g., provide dim light upon return form a stressful appointment), provide inspiration after a difficult appointment (e.g., quotes, movies, music, smells, sounds, etc.), present movies or music based on activities of the patient (e.g., recognizing boredom via the patient switching rapidly between activities), welcoming the patient back to the room after an appointment (e.g., “Welcome back Joe, you did great!”), provides a reel of pictures provided by the patient or associates of the patient (e.g., family members can provide a stream of photos or videos to provide encouragement to the patient), and recognizes that additional individuals (e.g., family or friends) are in the sentient patient room and adjusts operation to better accommodate the group. The system 1000 can utilize big data (e.g., purchase history, ad info, etc.) to improve the base profile policy and more accurately predict how the patient will prefer the sentient patient room to react to various actions. Other actions and functionality of the sentient patient room can be provided by the system 1000 within the scope of this concept. The use of an artificial intelligence engine can be used to predict and respond to patient actions and activities to improve patient care.

[0120] In some embodiments, system 1000 is configured to improve the patients and clinicians surroundings, including lighting conditions, air temperature, privacy and noise.

In some embodiments, this can make the difference for a successful intervention of the care team. System 1000 may be configured to decrease response delays, decrease distractions from focusing on patient care, decrease HVAC system lagging, improve readiness of access to patient information, and decrease potential negative patient outcomes.

[0121] In some embodiments, system 1000 is speeds staff response (e.g., in an emergency situation when every second could influence patient survival, etc.). Care team staff may receive immediate notifications with patient status, as well as room number to help with wayfmding. Automated controls can shift room features to the optimal setting, and the healthcare team can be free to focus immediately and fully on assessing, resuscitating, and otherwise stabilizing the patient. System 1000 may include providing care team notifications with room number and staff arrival status, patient event dashboard(s) including meals, medications, and/or allergies, automated HVAC zone temperature change, and/or, automated controls for lighting, TV, shades room settings, and any combination thereof.

Smart Room Integration 36 [0122] Referring now to FIG. 11, a system 1100 with a command center engine with smart room integration is shown, according to some embodiments. System 1100 is shown to include patient room 1002 that can integrate with the patient room 1002 with application requests from one or more occupants (e.g., a patient 1102, friends/family 1118, etc.) and other systems within building 10. In some embodiments, system 1100 can be incorporated partially or entirely within system 1000, or vice versa.

[0123] The patient room 1002 is shown to include the patient 1102, a user device 1104, a room application 1106, TPH sensors 1112, lighting sensors 1116, friends/family 1118, the command center engine 502, and friends/family 1118. The friends/family 1118 located within the patient room 1002 provide updates or requests to the application 1106, along with the patient 1102. In some embodiments, there is hierarchy of which requests can be considered for implementing.

[0124] TPH sensors 1112 may be configured to monitor environmental conditions within room 10002. Lighting sensors 1114 may be configured to monitor the amount of light within patient room 1002 (e.g., lumens, etc.). Friends/family 1118 may be the friends and/or family of the patient that has entered patient room 1002. User device 1104 may be any device capable of accessing any one of the systems within supersystem 500 via the Internet, an application, or any combination thereof, such as a smartphone or tablet. Room application 1106 may be hosted on premise (e.g., within a server in building 10, etc.) or off- premise (e.g., stored on a server at a datacenter, etc.), and may be hosted as an application on user device 1104.

[0125] For example, if the patient 1102 requests a temperature decrease, while a friend of friends and family 116 requests a temperature increase, the room application 1106 (e.g., via a control signal manager 1108, etc.) may implement a control signal to satisfy the request of the patient 1102. In some embodiments, one or more requests to adjust manipulated variables from any of the occupants in the patient room 1002 can be implemented simultaneously. In some embodiments, friends and family 1118 are located outside of the patient room 1002, and can similarly make requests. In the above example relating to hierarchy, requests from the friends and family 1118 may be lower in hierarchy than the occupants within the patient room 1002. 37 [0126] Control signal manager 1108 may be configured to provide control signals to HVAC equipment, provide care team updates to the care team of the patient 1102, and provide room preference changes to one or more building occupants (e.g., hospital administrator, etc.).

Patient Recognition

[0127] Referring now to FIG. 12, a system 1200 with a command center engine with patient recognition functionality is shown, according to some embodiments. System 1200 is shown to include video cameras 1214, 1216, the command center engine 502 including a video feed receiver 1202, facial recognition manager 1204, user profiles 1206, a security manager 1208, and a notification system 1210. The system 1200 is also shown to include the care team hub 716 and the registration system 512.

[0128] In some embodiments, system 1200 is configured to receive occupant data (e.g., facial recognition data from one or more occupants that enter building 10, etc.), process the facial recognition data, determine the detected occupant, and provide control actions based on the detected occupant. Video feed receiver 1202 may be configured to receive video feed (e.g., live video feed, etc.) and process the data such that it can be readable for facial recognition manager 1204. Facial recognition manager 1204 may be configured to determine the occupant detected from the live video feed based on stored user information (e.g., user profiles, etc.) from user profiles 1206.

[0129] Facial recognition manager 1204 may be configured to provide the detected occupant to security manager 1208 and notification system 1210. In some embodiments, security manager 1208 to determine if the incoming occupant is known, is a threat, requires security concern, or a combination thereof. Notification system 1210 may be configured to determine one or more registration updates (e.g., patient profiles in the building, etc.) and provide that information to registration system 512. In some embodiments, notification system 1210 may also be configured to provide patient updates to care team hub 716, in the event that the occupant is the patient and the care team can be updated about the incoming patient. While not shown in FIG. 12, system 1200 may also facilitate notification updates being provided to the occupant, such as providing instructions to the required room, etc.

Intelligent Code Blue System 38 Code Blue Method

[0130] As shown in FIG. 13, an intelligent code blue method 1300 for implementing a response to a patient during an emergency is shown, according to some embodiments. The method 1300 provides coordination between the patient and the clinician via the command center engine 502 to enact efficient and effective medical response to a patient emergency. In some embodiments, the command center engine 502 may be replaced by a local controller, or an intelligent code blue system architecture 1400 as discussed below. In some embodiments, the intelligent code blue system architecture 1400 is included in the command center engine 502.

[0131] In some embodiments, the emergency includes a code blue event. Code blue is the most universally recognized emergency code within a hospital setting and indicates that there is a medical emergency occurring within the hospital. Healthcare providers can choose to activate a code blue event, typically by pushing an emergency alert button or dialing a specific phone number, if they feel the life of the person they are treating is in immediate danger. Many hospitals have a code blue team who will respond to the code blue event as quickly as possible (e.g., within minutes). The code blue team may include doctors, nurses, a respiratory therapist, and a pharmacist. Some common reasons for activating a code blue event can include cardiac arrest, respiratory arrest, severe confusion, not alert or lack of consciousness, or shows signs of stroke, and/or sudden and severe drop in blood pressure. With any code blue medical event, patient safety rises above all else.

For the critical responses these situations demand, every second counts. Precision, focus, and efficiency matter and so does the room environment where these lifesaving measures unfold. Optimizing the patient’s and clinicians’ surroundings including lighting conditions, air temperature, privacy and noise can tip the scales for a successful intervention. Controlling a code blue environment builds a foundation for the best possible outcomes. Current systems suffer from response delays, including finding and adjusting features in the patient’s room, distractions from focusing on patient care, HVAC system lag in changing zone temperature, lack of ready access to patient information, and other room specific issues that can lead to less desirable patient outcomes.

[0132] The intelligent code blue method 1300 speeds staff response when every second is key to patient survival. Care team staff receive immediate notifications with patient status, as well as room number to help with wayfmding. Automated controls shift room features 39 and/or parameters to more optimized settings, keeping the healthcare team free to focus on immediately and fully assessing, resuscitating, and otherwise stabilizing the patient. Features of the intelligent code blue method 1300 include one-button code blue launch, care team notifications with room number and staff arrival status, patient event dashboard including meals, medications, allergies, automated HVAC zone temperature change, automated controls for lighting, TV, shades and room settings, and seamless integration with building systems and technology. The systems described above provide the infrastructure to enable the use of the intelligent code blue method 1300, and the benefits of the intelligent code blue method 1300 include greater operational efficiency, improved critical response team productivity, greater patient satisfaction with higher net promotor scores, improved HCAHPS scores, and enhanced hospital image. The critical response team can focus immediately on the patient, rather than the room environment, saving time when every second may affect patient outcomes. Advanced messaging, alarms and notification lookups quickly notify critical response team members for participation in person or by video. Room devices can be monitored and controlled without human intervention. Intelligent Code Blue automates the change to optimal room conditions, supporting the potential for positive outcomes. Fully digital, app-based controls adjust the patient room technologies automatically. Digital tools minimize physical touches by staff and patients, while increasing flexibility with options such as broadcasting a collaboration video to the room’s TV. Optimizing Code Blue response increases staff satisfaction and promotes more effective collaboration among in-person and video participants. As patient care improves, patient and staff satisfaction increases and the hospital’s positive reputation grows.

[0133] At step 1304, the patient is admitted to a room and the details of the patient and required medical assistance is entered into the command center engine 502 so that scheduling and coordination as discussed above can be integrated. In some embodiments, the patient is checked into a smart room or a sentient patient room. In some embodiments, the patient’s preferences, historical information, and/or demographic information are loaded into the command center engine 502, and more specifically into PPMS 534, as described above.

[0134] At step 1308, a clinician, other hospital worker, or any of the automated check in systems discussed herein admit the patient into an admission, discharge, and transfer (ADT) 40 system of the hospital. In some embodiments, the ADT is built into the command center engine 502 and the patient is automatically checked in upon arrival at the facility. In some embodiments, the patient admission is initialized by the patient at step 1304 and finalized at step 1308.

[0135] At step 1312, a clinician and/or a care team is assigned to the patient. In some embodiments, the clinician is assigned immediately after the patient is admitted and the assignment is not affected or in response to the symptoms recognized in step 1316, as described below. In some embodiments, the clinician is assigned after step 1316 in the assignment is based at least in part on the types of symptoms observed by the system.

[0136] At step 1316, the patient begins to experience symptoms that may lead to a code blue event. In some embodiments, the symptoms can include shortness of breath, chest pain, or increased heart rate. In some embodiments, the symptoms are recognized automatically by the sentient patient room via direct monitoring (e.g., a heart rate monitor) or via intelligent observation (e.g., patient is clutching chest, wincing, etc.).

[0137] At step 1320, a code blue button is optionally activated (e.g., a friend or family member presses an RN button on the nurse call pillow speaker) and a notification is sent to the assigned clinician. In some embodiments, the code blue button is engaged automatically by the command center engine 502 or another system of the sentient patient room in response to the symptoms recognized in step 1316. In some such embodiments, an automated code blue system or method may be implemented that automatically detects and/or initiates a code blue event (e.g., based on the patient’s vital signs). The notification provides the clinician with instant access to the symptoms and any other information (e.g., classification and/or diagnostic codes, as discussed above) that triggered the engagement of the code blue button. When the clinician arrives in the patient’s room, he or she already has information on the code blue event and can focus on confirmation of the notification information.

[0138] At step 1324, the clinician confirms the code blue event and the intelligent code blue method 1300 engages the full response team to mitigate the problems associated with the code blue event.

[0139] At step 1328, the patient room responds to the confirmed code blue event and automatically adjusts the temperature, pressure, and humidity and/or any other room 41 systems (e.g., blinds, air purification, etc.) to provide an optimum environment for critical care. In some embodiments, the temperature and/or humidity of the room are automatically lowered in response to a code blue event. Lowering the temperature and/or humidity of the room may not only benefit the patient, but can benefit a care team and/or the assigned clinician, who may have to rush (e.g., run) to the patient’s room, causing increased body temperatures and respirations, etc. As the room is automatically adjusting conditions for response, a notification is sent via the command center engine 502 to the code blue response team.

[0140] At step 1332, the assigned clinician administers immediate resuscitation or other code blue procedures and awaits the arrival of the code blue team. In some embodiments, a camera and/or display (e.g., a television) positioned in the patient’s room is also activated, allowing a remote supervising clinician to support the assigned clinician in administering code blue procedures.

[0141] At step 1336, the code blue team arrives and stabilizes the patient. The command center engine 502 receives input through the code blue event and can automatically schedule a care room or facility that is appropriate for the patient’s care after the code blue event. For example, if an emergency surgery is required in view of the code blue event, the command center engine 502 automatically schedules an OR and the code blue team is provided with wayfmding information for transferring the patient to the scheduled OR.

[0142] The patient or family of the patient can push a button to call a nurse (e.g., via a pillow speaker, etc.). The clinician can get notified and go to the patient’s room to find the patient in distress. Subsequently, the clinician can engage an emergency alert (e.g., via a button, etc.). The patient’s room is then optimized for the ideal care of the patient. For example, if the patient had adjusted the TPH levels to their preference, but were not necessarily ideal for their health, engaging the button that the clinician pressed can return the TPH levels back to levels that are optimal for the patient’s health, even it compromises some of the comfort of the patient. In addition, the emergency button engaged by the clinician can send an alert to a critical care team, who can respond and assist in helping the patient.

Code Blue System Architecture 42 [0143] Referring now to FIG. 14, an intelligent code blue system architecture 1400 includes several servers (e.g., building management system server, nurse call server, etc.) and other sensor/ API-based information being connected to an “intelligent code blue” system. In some embodiments, the intelligent code blue system architecture 1400 can include an alert/notification system and BMS adjustment that is engaged when one or more people of the care team of the patient engages the system (e.g., via a button, etc.). The intelligent code blue system architecture 1400 may also be connected to a room control system (e.g., system 1000, system 1100, etc.) configured to adjust room entertainment, HVAC, lighting, shading, alert signals, video, or any combination thereof.

[0144] As shown in FIG. 14, the intelligent code blue system architecture 1400 includes an intelligent code blue engine in the form of an integration engine 1404 that is structured to receive and interpret information, determine a code blue event, and enact code blue actions in response to determining a code blue event. In some embodiments, the integration engine 1404 receives information from a code blue button 1408 (e.g., in the patient room, at a nurse station, provided as an interactive button of a graphical user interface (GUI), a remote button, etc.) that can be engaged by a clinician (e.g., as shown in step 1324 of the method 1300). The integration engine 1404 can also communicate with a nurse call server 1412, a building automation system 1416 that can include the BMS 400 and/or the command center engine 502, and a wayfmder system 1420 for aiding clinicians get to the code blue event room. In some embodiments, the code blue button 1408 is a response button. In some embodiments, the response button can indicate an emergency, a contagious disease risk, or another event that requires automatic action of the intelligent code blue system architecture 1400.

[0145] In some embodiments, the integration engine 1404 provides information to the nurse call server 1412 to coordinate activities of the clinical staff. In some embodiments, the integration engine 1404 receives information from the nurse call system 1412 in the form of patient calls (e.g., a patient or other room occupant pressing the nurse call button), nurse and other clinical staff scheduling information (e.g., who is currently staffed, on-call individuals, clinician locations within the hospital, etc.), and/or other information.

[0146] In some embodiments, the integration engine 1404 provides information to the building automation system 1412 including room identity information (e.g., a room ID code, a room number, a room location, etc.), current patient information, room conditions at 43 the time of a response event in the form of a code blue event, and other information, as desired. In some embodiments, the integration engine 1404 receives information from the building automation system 1412 including historical building information, operational status information for building systems (e.g., air handlers, chillers, door open status, air quality, temperature, pressure, humidity, etc.), or any other information available to the building automation system 1412.

[0147] In some embodiments, the wayfmder system 1420 is provided via lighted floors, video panels arranged in the hallways of the hospital, audio speakers, overhead lighting, or other physical elements within the hospital. In some embodiments, the wayfmder system 1420 is provided via a graphical user interface (GUI) of an application that can be accessed by a care provider via a smart phone, tablet, or other device. The GUI can provide real time location information and directions through the hospital. The wayfmder system 1420 can provide assistance to medical staff responding to the code blue event and reduce the time required for travel to the room where the code blue event is happening. The wayfmder system 1420 sends location information of a user (e.g., a medical professional) to the integration engine 1404 and receives information (e.g., directions, maps, etc.) from the integration engine 1404.

[0148] The integration engine 1404 communicates with a room control system 1424 to enact actions of the intelligent code blue system architecture 1400 (e.g., actions of the method 1300, response actions to a patient fall emergency, response actions to a contagious disease emergency, etc.). In some embodiments, the room control system 1424 controls room features including an entertainment center 1428, an HVAC system 1432, a lighting system 1436, a shades system 1440, an alert signal system 1444, a video system 1448, an oxygen supplement system 1450, and or other systems. In some embodiments, the room control system 1424 is in direct control of the room features. For example, the room control system 1424 can include or be a part of the BMS 400 discussed above and in control of HVAC systems and subsystems and other room features. In some embodiments, the room control system 1424 controls one or more room features, but not all room features, as desired. For example, the room control system 1424 can control the HVAC system 1432 and the lighting system 1436, but not the entertainment center 1428. In some embodiments, the room control system 1424 provides instructions to systems and subsystems associated with the room features to provide a coordinated response to the code blue event. For 44 example, the room features may be controlled by any combination of local controllers and offsite controllers and the room control system 1424 provides instructions to the controllers (e.g., local, distributed, cloud based, off site, etc.) to enact the desired actions in response to the code blue event.

[0149] As shown in FIG. 15, some embodiments of the intelligent code blue system architecture 1400 include the integration engine 1404. The integration engine 1404 is located on-premises or locally. Generally, the nurse call system 1412 is structured to communicate with the integration engine 1404 via a snap box 1452 and provide a room identifier and a response identifier in the form of a code blue identifier to the integration engine 1404. An electronic medical record and admission discharge transfer (EMR/ADT) system 1454 communicates with the integration engine 1404 to provide patient related information including allergies, medication restrictions, health history, current medical treatment plans, historical doctor information, etc. The integration engine 1404 also communicates with a network system in the form of a cloud 1456. The cloud 1456 provides communication and control between the integration engine 1404, and enterprise management system 1460, and a companion system 1464. In some embodiments, the enterprise management system 1460 is the BMS 400 or the BMS controller 366, or any portion of the BMS 400 or the BMS controller 366, or any portion of enterprise management components, systems, or subsystems discussed above. In some embodiments, the companion system 1464 is an application in communication with the integration engine 1404 and/or the enterprise management system 1460 and can be provided on a user device such as a smart phone in order to convey information to a user (e.g., a medical professional) via a graphical user interface (GUI) and to receive information from the user via interaction with the GUI using buttons (e.g., real, virtual, digital touch screen, GUI buttons, etc.). The integration engine 1404 communicates with an application data server (ADS) or extended application and data server (ADX) 1468 and an Intemet-of-Things (IoT) device interface 1472 to enact actions during a code blue event in response to the room identifier and the code blue identifier. The intelligent code blue system architecture 1400 is structured to identify a code blue event (e.g., from the nurse call system 1412), then control room features (e.g., temperature, lighting, air flow, oxygen levels, etc.) during the event. In some embodiments, the intelligent code blue system architecture 1400 is structured to provide communication to the companion system 1464 and the nurse call system 1412 to coordinate actions of medical staff responding to the code blue event. For example, the companion 45 system 1464 may provide wayfmding instructions to medical staff, thereby decreasing the time to arrive at the room where the code blue event is occurring. Additional advantages and benefits of the intelligent code blue system architecture 1400 will be apparent from the following description. In some embodiments, the system architecture 1400 can be used to automatically respond to other emergencies or events. For example, concepts discussed herein may be applied to a patient fall emergency (e.g., when a patient falls within the hospital, or become incapacitated in a non-life threatening way), or a rapidly spreading contagious disease event. While the description herein refers to code blue events, it is understood that events other that code blue events can act as the prompt for actions, and actions other than the code blue actions discussed below can be implemented in response.

[0150] In some embodiments, the nurse call system 1412 is structured to output a text string. The snap box 1452 is structured to parse the text string into data packets and provide the data packets to the integration engine 1404 is a format suitable for use by the integration engine 1404. In some embodiments, the nurse call system outputs consumable data packets directly to the integration engine 1404. For example, the nurse call system 1412 can output a room signal that directly identifies the room in which a code blue event is occurring and a code blue signal indicating that a code blue event is ongoing. The room signal and the code blue signal can be directly communicated to the integration engine 1404 to allow the intelligent code blue system architecture 1400 to implement code blue actions (e.g., cool the room, increase air flow, maximize light, etc.) and to provide communication with the medical professionals to increase response time of the code blue team to the code blue event (e.g., via communication with the companion system 1464).

[0151] In some embodiments, the nurse call system 1412 outputs a text string including a room identifier and a code blue identifier. The room identifier may be a room number, a room code (e.g., hexadecimal ID number, etc.), or another identifier that allows the integration engine 1404 or another portion of the intelligent code blue system architecture 1400 to recognize the room in which the code blue event is occurring.

[0152] In some embodiments, the snap box 1452 receives the text string from the nurse call system 1412 and extracts the room identifier and the code blue identifier. For example, the snap box may utilize filtering techniques, programmed logic, a machine learning engine, or a rules based logic to determine the room identifier and the code blue identifier. For example, in some hospitals, the nurse call system 1412 may include relatively older 46 technology or may include a unique way of identifying rooms and code blue events (e.g., a room identifier and a code blue identifier that are unique to that one hospital). The snap box 1452 includes logic, machine learning engines, or other programming that allows for the integration with an existing, and sometimes older technology, nurse call system 1412 with the integration engine 1404 and allows an older nurse call system 1412 to enjoy the benefits of the intelligent code blue system architecture 1400. In some embodiments, there the snap box 1452 utilizes machine learning, a reinforcement training scheme can be used to initialize a snap box model with historical information, then to further train the snap box model using real time nurse call information from the nurse call system 1412. In some embodiments, the snap box 1452 is a physical control module installed at an edge of the intelligent code blue system architecture 1400. For example, a snap box 1452 can be installed at each nurse station of a hospital to directly interact with the nurse call system 1412 where the medical staff interacts with the nurse call system 1412 (e.g., at a nurse station, in a section of a hospital floor, in a treatment unit, etc.). In some embodiments, the snap box 1452 may be included in the integration engine 1404 and an external physical module is not needed. In some embodiments, the snap box 1452 may be a regional or sectional physical module that is in communication with more than one nurse call system 1412 or more than one nurse call stations allowing for a single snap box 1452 to provide the room identifier and the code blue identifier from the more than one nurse stations to the integration engine 1404 and for use by the intelligent code blue system architecture 1400.

In some embodiments, the snap box 1452 may communicate with the cloud 1456, the enterprise management system 1460, and/or the companion system 1464.

[0153] The EMR/ADT system 1454 communicates with the integration engine 1404 to provide patient information including allergies, medication restrictions, health history, current medical treatment plans, historical doctor information, etc. The patient information can be used by the integration engine 1404 to communicate relevant information to the code blue team via the companion system 1464. For example, the code blue team may be provided with the patient information and have access to patient allergies, or other information that may inform treatment during response to the code blue event.

[0154] The network system of FIG. 15 is shown as the cloud 1456. In some embodiments, the network system can include a local server system, a remote server system, a distributed control and data storage system, or any combination of network 47 systems. In some embodiments, various data discussed herein may be processed at (e.g., processed using models executed at) the cloud 1456 or other off-premises computing system/device or group of systems/devices, an edge or other on-premises system/device or group of systems/devices, or a hybrid thereof in which some processing occurs off-premises and some occurs on-premises. In some example implementations, the data may be processed using systems and/or methods such as those described in U.S. Patent Application No. 17/710458 filed March 31, 2022, which is incorporated herein by reference in its entirety. In some embodiments, aspects of the enterprise management system 1460 and/or the companion system 1464 may be incorporated into the cloud 1456 or other network system(s). Additionally, in some embodiments, various data discussed herein may be stored in, retrieved from, or processed in the context of digital twins. In some such embodiments, the digital twins may be provided within an infrastructure such as those described in U.S. Patent Application Nos. 17/134,661 filed December 28, 2020, 63/289499 filed December 14, 2021, and 17/537,046 filed November 29, 2021, the entireties of each of which are incorporated herein by reference.

[0155] In some embodiments, the enterprise management system 1460 is the BMS 400 or the BMS controller 366, or any portion of the BMS 400 or the BMS controller 366, or any portion of enterprise management components, systems, or subsystems discussed above.

The enterprise management system 1460 can control building systems to affect the environment in the room where the code blue event is occurring. For example, the enterprise management system 1460 may control air handlers, chillers, other HVAC components, louvers, lighting, shades, and any other room features that affect the environment. In some embodiments, the enterprise management systeml 460 is also connected to auxiliary systems such as an entertainment system, and alert system, a video system, etc. For example, an entertainment system in the room may be automatically operated in response to a code blue event to display patient information, vital statistics, room parameters (e.g., temperature, pressure, humidity), locations of other members of the code blue team, etc. In some embodiments, the entertainment system and the video system may cooperate to provide an interactive environment that aids the code blue team. For example, a remote medical professional (e.g., an expert, a patients general practice doctor, etc.) may be connected to the entertainment system to communicate with the code blue team to increase the likelihood of survival of the patient. The video system could allow communication from the code blue team to the remote medical professional. 48 [0156] In some embodiments, the companion system 1464 is coordinated with the integration engine 1404 and the enterprise management system 1460 to provide coordinated communication to the code blue team and/or other medical professionals, family and friends, etc. For example, the companion system 1464 can include an application operable on a mobile device that provides a graphical user interface (GUI) for communicating information to a user and receiving information from the user. For example, the GUI can provide an alert to the code blue team that a code blue event has been triggered. A room location may then be provided and wayfaring information provided to speed the code blue teams arrival. The GUI may provide communication between the code blue team to provide additional coordination. Additionally, the code blue team can be connected with a primary care team for the patient to gain insight and information regarding the patient before arriving at the room. The GUI may also provide patient information before the code blue team arrives at the room. The companion system 1464 allows the code blue team to be more well prepared when they arrive at the room and therefore be more efficient with care and increase the likelihood of survival.

[0157] The ADS/ADX 1468 connects to devices at the edge of the intelligent code blue system architecture 1400 and manages the collection of large amounts of trend data, event messages, operator transactions, and system configuration data. The ADS/ADX 1468 provides site unification, advanced reporting, a simple and intuitive user interface, and a hierarchical network view of the intelligent code blue system architecture 1400 for all connected devices, which allows for efficient control of energy usage, quick response to critical conditions, and optimization of automation strategies. In some embodiments, the ADS/ADX 1468 provides fault detection at the edge. For example, the ADS/ADX 1468 identifies and lists building system-related faults in order of severity to help operators quickly fix issues and avoid equipment issues, energy waste, and comfort complaints. Fault detection can include fault triage that provides fault duration, occurrence information, and corrective action recommendations to improve fault prioritization that assists less experienced building operators with problem solving. In some embodiments, the ADS/ADX 1468 provides a building network tree that allows for faster delivery of user interfaces (UI) of the enterprise management system 1460 by enabling deployment prior to the spaces and equipment configuration process. In some embodiments, the ADS/ADX 1468 provides an advanced search and reporting features that accesses the enterprise management system 1460 to find and report on operational data and make bulk commands 49 to restore order more quickly. For example, the advanced search and reporting feature can provide users the ability to quickly search enterprise management system 1460 objects by the building network, equipment, equipment type, or space. In some embodiments, the ADS/ADX 1468 provides custom dashboards for the enterprise management system 1460 and enable designers to create dashboards that provide the most relevant and critical information for enhanced productivity and creates an experience that mimics users operational styles for ease of use. In some embodiments, the custom dashboards can be provided to users via a mobile application of the companion system 1464. In some embodiments, the ADS/ADX 1468 provides graphics custom behaviors including custom symbols for individual buildings, campus needs, local standards, etc. In some embodiments, the ADS/ADX 1468 provides trend widget updates that allow users to identify patterns including outliers, using intuitive candlestick charts that display min, max, and averages. In some embodiments, the ADS/ADX 1468 provides a cyber health dashboard with a centralized view of potential security-related issues or system issues which are detectable by the ADS/ADX 1468, but which may not surface as part of general system alarms. In some embodiments, the ADS/ADX 1468 provides user management that facilitates the creation and management of users and their roles within the intelligent code blue system architecture 1400 including category based permissions and privileges. In some embodiments, the ADS/ADX 1468 provides historical data management, including an Open Database Connectivity (ODBC) compliant database package for storage of trend data, event messages, operator transactions, and system configuration data. A site management portal UI of the ADS/ADX 1468 provides a flexible system to change the online configuration of the enterprise management system 1460, optimize control strategies, and perform administrative tasks. The ADS/ADX 1468 includes an ODBC compliant database package for secure storage of historical and configuration data. The ADS/ADX 1468 supports virtual environments, including VMware® and Microsoft® Hyper- V™.

[0158] The IoT device interface 1472 provides communication between the integration engine 1404 and a variety of IoT connected devices (e.g., lighting, shades, HV AC/Temp, TV/entertainment, etc.). The IoT device interface 1472 can call a resting IP Application Programming Interface (API) of each individual IoT connected device to receive information therefrom and to provide control from the integration engine 1404 to the IoT connected device. The IoT device interface 1472 provide integration of IoT devices (e.g., third party provided devices, devices inclusive of the intelligent code blue system 50 architecture 1400, any other IoT capable device) with the intelligent code blue system architecture 1400. The IoT device interface 1472 improves the system’s ability to be integrated into existing system and hospitals while providing the advantages and benefits of the intelligent code blue system architecture 1400.

[0159] The integration engine 1404 includes programming that allows communication with the IoT device interface 1472 and integration of the IoT connected devices into the intelligent code blue system architecture 1400. In some embodiments, the integration engine 1404 include Node-RED programming that provides a logical flow based development environment allowing for visual programming of inputs, outputs, and actions of the integration engine 1404. The integration engine 1404 integrates hardware devices, APIs and online based services as a part of the IoT. Node-RED provides a light-weight runtime built on Node.js, and an event-driven, non-blocking model. The integration engine 1404 including Node-RED is ideal to run at the edge of the intelligent code blue system architecture 1400 and can be supported on relatively low-cost local hardware, in the cloud 1456, on a distributed network, or any combination thereof.

Method of Operation of an Intelligent Code Blue System Architecture

[0160] As shown in FIG. 16, the intelligent code blue system architecture 1400 can be arranged and operated using the method 1476. At step 1480, code blue actions are defined in the integration engine 1404. Code blue actions can include and actions desired by the hospital and can include HVAC control, lighting control, shade control, security control, control of communications to the code blue team, control of communications to the primary care team, control of communications to the patient’s family and/or friends, control of video camera systems, control of entertainments systems, control of an alert system, and/or other controls as desired. In some embodiments, the code blue actions are defined using the Node-RED environment discussed above. For example, the Node -Red environment can be used to define input nodes, processing nodes, and output nodes within the integration engine 1404 to provide the desired code blue actions. In some embodiments, the integration engine 1404 will communicate with the cloud 1456, the enterprise management system 1460, the companion system 1464, the nurse call system 1412, the EMR/ADT system 1454, the ADS/ADX system 1468, and/or the IoT device interface 1472 to define and control the input nodes, processing nodes, and output nodes. Control of the input node, processing 51 nodes, and output nodes during operation of the method 1476 results in the implementation of the code blue actions, as desired.

[0161] In some embodiments, the HVAC control can control operation of the HVAC 1432 to lower the temperature of the room (e.g., the room 1002) to a set point temperature. In some embodiments, the HVAC control can adjust the HVAC 1432 to a coldest setting to drop the temperature as rapidly and as cold as permitted by the HVAC system constraints.

In some embodiments, HVAC control defines an air flow or circulation rate (e.g., a turn over time, a turn over volume, etc.) and adjusts air handlers to achieve the air flow or circulation rate.

[0162] In some embodiments, the lighting control can control the lighting 1436 to provide a maximum illumination in the room and/or on a path to the room. For example, the hospital lighting system may be controlled to illuminate any areas through which a member of the code blue team may travel on their way to the room.

[0163] In some embodiments, the shade control operates the shades 1440 to allow a maximum of ambient light through any windows of the room. In some embodiments, the shade control can operate the shades 1440 to block visibility into the room (e.g., from an adjacent hallway, etc.).

[0164] In some embodiments, the security control can automatically unlock doors on the path between the code blue team and the room. Automatic control of safety doors may reduce the time required for the code blue team to arrive at the room and administer care.

[0165] In some embodiments, the control of communications to the code blue team can include communication using the companion system 1464 and may provide the code blue team with vital patient information, patient EMR/ADT information, communication or locations of other code blue team members, wayfaring information, etc. In some embodiments, the control of the communications to the code blue team can include paging the code blue team using personal pagers, group or floor level paging, department level paging, phone calls, or another form of communications. In some embodiments, the control of communications to the code blue team includes controlling video boards, or directional lighting to aid in wayfmding or wayfaring to aid in the speedy arrival of the code blue team in the room. 52 [0166] In some embodiments, the control of communications to the primary care team can include communication using the companion system 1464 and may provide the primary care team with vital patient information, patient EMR/ADT information, communication or locations of the code blue team members, instruction for treatment until the code blue team arrives (e.g., how to conduct preliminary actions and life saving techniques), etc. In some embodiments, the control of communications to the primary care team includes controlling the entertainment system 1428 to display information to the primary care team.

[0167] In some embodiments, the control of communications to the patient’s family and/or friends can include communication using the companion system 1464 and may provide information about the patient, where they can meet the primary care team and/or the code blue team after the code blue event has concluded, etc.

[0168] In some embodiments, the control of video camera systems can include the ability for live interaction of the code blue team and/or the primary care team with a remote expert or individual who would like to communicate during the code blue event. The video system 1448 can provide sounds and video feed out to other, remote systems.

[0169] In some embodiments, the control of entertainments systems can include operation of the entertainment system 1428 to display patient information, aids for treatment, provide communication with an offsite expert or individual with information valuable to the code blue event, etc.

[0170] In some embodiments, the control of an alert system can be used to alert the code blue team or other individuals or groups who need to be aware of the code blue event.

Alerts 1444 can include audible alarms, text messages, pages, alerts provided through the companion system 1464, or another type of alert, as desired.

[0171] At step 1484, the integration engine 1404 receives nurse call information from the nurse call system 1412. In some embodiments, the nurse call information includes a data packet in the form of a text string. The text string includes a code blue identifier and a room identifier. The code blue identifier indicates that a code blue event is occurring. The room identifier indicates a room location or code that allows the integration engine 1404 to determine the room where the code blue event is occurring and to provide location information of the room to the code blue team. In some embodiments, the location information can include a location of a nearest crash cart or other code blue related supplies 53 and/or equipment. In some embodiments, the text string is parsed by the snap box 1452 in order to convert the raw information provided by the nurse call system 1412 to a data format usable by the integration engine 1404. In some embodiments, the nurse call system 1412 communicates directly with the integration engine 1404 and provides the code blue identifier and the room identifier in a format consumable by the integration engine 1404. In some embodiments, the nurse call system 1412 sends the nurse call information when a code blue button is pressed. The code blue button can include a physical button at a nurse station or on a mobile device, etc. or may be a digital or UI button provided on a touch screen or a mobile device (e.g., via the companion system 1464).

[0172] At step 1488, a status is returned to the integration engine 1404 and/or other components of the intelligent code blue system architecture 1400. For example, the existence of an active code blue event may be provided to the enterprise management system 1460, the companion system 1464, the cloud 1456 or another network system, the ADS/ADX 1468, and/or the IoT device interface 1472. The status may be used for logging or control actions.

[0173] At step 1492, the integration engine 1404 analyzes the nurse call information received at step 1484, parses the code blue identifier, and determines if the code blue identifier indicates an active code blue event. In some embodiments, the nurse call information only includes the code blue identifier if an active code blue event is occurring. In some embodiments, the code blue identifier is a first value (e.g., true, 1, etc.) if an active code blue event is occurring, and a second value (e.g., false, 0, etc.) if there is no active code blue event.

[0174] If the code blue identifier indicates no active code blue event (e.g., no code blue identifier included in the nurse call information, 0, false, etc.) then the method 1476 ends at step 1496 and continues to wait for further nurse call information.

[0175] If the code blue identifier indicates an active code blue event is ongoing (e.g., the code blue identifier is included in the nurse call information, 1, true, etc.) then the method 1476 continues to step 1500 and the room identifier is parsed and used to determine the room location.

[0176] At step 1504, the integration engine 1404 looks up a fully qualified reference (FQR) for the identified room. The FQR is a unique, user-defined name that identifies an 54 object in the intelligent code blue system architecture 1400. In some embodiments, the identified room includes the FQR for all related room systems (e.g., lighting, HVAC, shades, etc.). In some embodiments, FQRs of each associated system and room object are looked up at step 1504.

[0177] At step 1508, each FQR associated with the identified room is set to write (e.g., initialized so that a status or operational characteristics of the associated object can be changed). In some embodiments, step 1508 opens each FQR associated with the identified room for editing or writing by the integration engine 1404 or another component of the intelligent code blue system architecture 1400.

[0178] At step 1512, each FQR is set to indicate an active code blue event. In some embodiments, step 1512 writes the FQR’s of each associated device or system to true (e.g., 1, active, etc.) for code blue event. This indicates to the intelligent code blue system architecture 1400 and all included systems that a code blue event is occurring.

[0179] At step 1516, the integration engine 1404 initiates and controls the code blue actions. Initiation of the code blue actions results in the actuation of all desired room associated systems to produce the desired environmental and experiential result in the room during the code blue event. For example, the temperature of the room will be lowered to account for the larger number of bodies who will be occupying the room and inhibit the temperature in the room from raising to an unacceptable level during the code blue event. The code blue actions provide an automated response to the initiation of the code blue event and increase the medical staff and code blue team’s likelihood for success in the code blue event.

Intelligent Code Blue System Architecture

[0180] As shown in FIG. 17, in some embodiments an intelligent code blue system architecture 1520 includes the enterprise management system 1460 and the enterprise management system 1460 includes the integration manager 1404 and a HV AC/lighting control 1524 structured to control operation of room lights 1528, room shades 1532, room HVAC 1536 and room security 1538. In some embodiments, the HV AC/lighting control 1524 includes a number of distributed control modules located locally within the room (e.g., the room 1002) or near the room. In some embodiments, the HV AC/lighting control 1524 includes a centralized control located onsite (e.g., in a local server), at the edge, a 55 distributed control network (e.g., residing in one or more servers located locally to the room or hospital or remote from the room or hospital), or any combination thereof. In some embodiments, the HV AC/lighting control 1524 initiates or controls the implementation of the code blue actions discussed above.

[0181] The integration engine 1404 also communicates with a patient engagement system 1540 and an AV distribution system 1544. In some embodiments, the patient engagement system 1540 controls room speakers, television displays and/or other room displays, hallway displays, hallway speakers, and/or other features that the patient may interact with. In some embodiments, the AV distribut8ion system 1544 coordinates and controls digital white boards, clinical computers, video control computers, video cameras, speakers, badge tap devices, and/or other devices controlled by or interacted with by the medical staff or other hospital employees. In some embodiments, a video box 1548 provides communication from the patient engagement system 1540 to the AV distribution system 1544 to allow for coordination of the medical teams requirements for care and the patient’s needs. Additionally, the EMR/ADT system 1454 provides information to the patient engagement system 1540, and the integration engine 1404.

[0182] The nurse call system 1412 provides information to the integration engine 1404 as discussed above. Additionally, the nurse call system 1412 can provide information to a code blue communication system 1552 structured to communicate with the code blue team. In some embodiments, the code blue communication system 1552 includes a personal page 1556, an overhead page 1560, and a department page 1564 that are arranged to communicate with the code blue team. For example, the personal age system 1556 may provide communication directly to a code blue team member via a pager, a mobile device (e.g., a text message, a phone call, etc.), or via the companion system 1464 discussed above. The overhead page system 1560 can provide an audible page to the code blue team based on location information (e.g., the page will be audible in the area where the code blue team members are currently). The department page system 1564 can provide an audible page to an entire area of the hospital (e.g., a floor, a department, a section, an area, etc.) so that the code blue team is alerted to the code blue event. The nurse call system 1412 can also communicate with a mobile device 1568 either directly or via the companion system 1460 to provide code blue team members with information regarding the code blue event. For example, the mobile device 1568 may display a room number (e.g., based on the room 56 identifier ), provide wayfinding directions to the room, provide wayfinding directions to a crash cart or other equipment/supplies, display vital statistics of the patient, display other patient information, or provide other information to the code blue team member to aid in response to the code blue event.

[0183] In some embodiments, the intelligent code blue system architecture 1520 includes a voice control system 1572 in communication with the nurse call system 1412 and the HV AC/light control 1524 to allow for voice control of room features and nurse call features. Voice control via the voice control system 1572 can provide efficiency during the time of determining if a code blue event is occurring and can decrease the response time of the code blue team to an identified code blue event. The nurse call system 1412 also receives information from the code blue button 1408 as discussed above. In some embodiments, the code blue event can be triggered by the voice control system 1572 and/or the code blue button 1408.

[0184] In some embodiments, the intelligent code blue system architecture 1520 includes a real-time locating system (RLTS) 1576 in communication with the nurse call system 1412, the patient engagement system 1540, the AV distribution system 1544, and the integration engine 1404 to provide location information usable by the intelligent code blue system architecture 1520. The location information can be used for wayfmding, and/or for controlling security doors to speed access of the code blue team in transit to the room. Location information can also be used by other systems as desired to coordinate the code blue team’s ability to respond quickly to the code blue event. In some embodiments, the location information can include information about a crash cart or other supplies and/or equipment related to the code blue event. For example, a code blue team member may be assigned responsibility for bring a crash cart to the room, and the location information can provide wayfmding information to the crash cart for that team member, thereby reducing the response time of the code blue team as a whole to the code blue event.

[0185] In some embodiments, the intelligent code blue system architecture 1520 includes a computer vision system 1580 that is capable of watching patient’s in rooms. The computer vision system 1580 can include a machine learning engine capable of determining activities of the patient. For example, the computer vision system 1580 may monitor the patient in conjunction with a vital signs monitor and determine that a code blue event is likely to occur for the patient. For example, the computer vision system 1580 may 57 detennine that the patient has been still for longer than a predetermined time and send an alert to the nurse call system 1412 to initiate a patient check. The computer vision system 1580 improves the primary care team’s ability to recognize and trigger a code blue event in a timely fashion thereby increasing the chance of survival. The intelligent code blue system architecture 1520 is capable of performing the method 1476 discussed above.

Configuration of Exemplary Embodiments

[0186] As utilized herein, the terms “approximately,” “about,” “substantially”, and similar terms are intended to have a broad meaning in harmony with the common and accepted usage by those of ordinary skill in the art to which the subject matter of this disclosure pertains. It should be understood by those of skill in the art who review this disclosure that these terms are intended to allow a description of certain features described and claimed without restricting the scope of these features to the precise numerical ranges provided. Accordingly, these terms should be interpreted as indicating that insubstantial or inconsequential modifications or alterations of the subject matter described and claimed are considered to be within the scope of the disclosure as recited in the appended claims.

[0187] It should be noted that the term “exemplary” and variations thereof, as used herein to describe various embodiments, are intended to indicate that such embodiments are possible examples, representations, or illustrations of possible embodiments (and such terms are not intended to connote that such embodiments are necessarily extraordinary or superlative examples).

[0188] The term “coupled” and variations thereof, as used herein, means the joining of two members directly or indirectly to one another. Such joining may be stationary (e.g., permanent or fixed) or moveable (e.g., removable or releasable). Such joining may be achieved with the two members coupled directly to each other, with the two members coupled to each other using a separate intervening member and any additional intermediate members coupled with one another, or with the two members coupled to each other using an intervening member that is integrally formed as a single unitary body with one of the two members. If “coupled” or variations thereof are modified by an additional term (e.g., directly coupled), the generic definition of “coupled” provided above is modified by the plain language meaning of the additional term (e.g., “directly coupled” means the joining of two members without any separate intervening member), resulting in a narrower definition 58 than the generic definition of “coupled” provided above. Such coupling may be mechanical, electrical, or fluidic.

[0189] The term “or,” as used herein, is used in its inclusive sense (and not in its exclusive sense) so that when used to connect a list of elements, the term “or” means one, some, or all of the elements in the list. Conjunctive language such as the phrase “at least one of X, Y, and Z,” unless specifically stated otherwise, is understood to convey that an element may be either X, Y, Z; X and Y; X and Z; Y and Z; or X, Y, and Z (i.e., any combination of X, Y, and Z). Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y, and at least one of Z to each be present, unless otherwise indicated.

[0190] References herein to the positions of elements (e.g., “top,” “bottom,” “above,” “below”) are merely used to describe the orientation of various elements in the FIGURES.

It should be noted that the orientation of various elements may differ according to other exemplary embodiments, and that such variations are intended to be encompassed by the present disclosure.

[0191] The hardware and data processing components used to implement the various processes, operations, illustrative logics, logical blocks, modules and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose single- or multi-chip processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, or, any conventional processor, controller, microcontroller, or state machine. A processor also may be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some embodiments, particular processes and methods may be performed by circuitry that is specific to a given function. The memory (e.g., memory, memory unit, storage device) may include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage) for storing data and/or computer code for completing or facilitating the various processes, layers and modules described in the present disclosure. The memory may be or include volatile memory or non-volatile 59 memory, and may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described in the present disclosure. According to an exemplary embodiment, the memory is communicably connected to the processor via a processing circuit and includes computer code for executing (e.g., by the processing circuit or the processor) the one or more processes described herein.

[0192] The present disclosure contemplates methods, systems and program products on any machine-readable media for accomplishing various operations. The embodiments of the present disclosure may be implemented using existing computer processors, or by a special purpose computer processor for an appropriate system, incorporated for this or another purpose, or by a hardwired system. Embodiments within the scope of the present disclosure include program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine- readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.

[0193] Although the figures and description may illustrate a specific order of method steps, the order of such steps may differ from what is depicted and described, unless specified differently above. Also, two or more steps may be performed concurrently or with partial concurrence, unless specified differently above. Such variation may depend, for example, on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the disclosure. Likewise, software implementations of the described methods could be accomplished with standard programming techniques with rule- 60 based logic and other logic to accomplish the various connection steps, processing steps, comparison steps, and decision steps.

[0194] It is important to note that the construction and arrangement of various systems (e.g., system 100, system 200, etc.) and methods as shown in the various exemplary embodiments is illustrative only. Additionally, any element disclosed in one embodiment may be incorporated or utilized with any other embodiment disclosed herein. Although only one example of an element from one embodiment that can be incorporated or utilized in another embodiment has been described above, it should be appreciated that other elements of the various embodiments may be incorporated or utilized with any of the other embodiments disclosed herein. 61

Claims

WHAT IS CLAIMED IS:

1. A building management system (BMS) of a building for controlling a healthcare facility, the BMS comprising: one or more processing circuits comprising one or more memory devices configured to store instructions thereon that, when executed by one or more processors, cause the one or more processors to: receive a signal indicating a code blue event in a room for a patient; and adjust at least one of a temperature, a pressure, a humidity level, a lighting system, or an air composition in the room automatically in response to the received signal.

2. The BMS of claim 1, wherein the one or more memory devices are further configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: adjust at least one of an entertainment system or a shade system in response to the received signal.

3. The BMS of claim 1, wherein the one or more processing circuits include one or more processing circuits located on-premises and comprising one or more memory devices, and wherein the one or more memory devices of the one or more processing circuits located on-premises are configured to store instructions thereon that, when executed by one or more processors, cause the one or more processors to: receive nurse call information including the signal from a nurse call system.

4. The BMS of claim 1, wherein the one or more processing circuits include one or more processing circuits located on-premises and comprising one or more memory devices, and wherein the one or more memory devices of the one or more processing circuits located on-premises are configured to store instructions thereon that, when executed by one or more processors, cause the one or more processors to: communicate with an internet-of-things device interface to receive information from associated internet-of-things connected devices; and 62 control one or more of the associated internet-of-things connected devices via the internet-of-things device interface to adjust at least one of the temperature, the pressure, the humidity level, the lighting system, or the air composition in the room automatically in response to the received signal.

5. The BMS of claim 1, wherein the one or more memory devices are further configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: communicate with an enterprise management system to provide coordinated control of building systems and reporting of actions taken in response to the received signal.

6. The BMS of claim 1, wherein the one or more processing circuits include one or more processing circuits located on-premises and comprising one or more memory devices, and wherein the one or more memory devices of the one or more processing circuits located on-premises are configured to store instructions thereon that, when executed by one or more processors, cause the one or more processors to: define a set of code blue actions that includes adjusting at least one of the temperature, the pressure, the humidity level, the lighting system, the air composition, an entertainment system, or a shade system in the room automatically in response to the received signal; and implement the code blue actions automatically in response to receiving the signal directly without control of any off-premises processing circuits.

7. The BMS system of claim 6, wherein the set of code blue actions includes defining inputs received by the one or more processing circuits located on-premises, processing steps performed by the one or more processing circuits located on-premises, and outputs provided by the one or more processing circuits located on-premises to other on-premises devices structured to adjust at least one of the temperature, the pressure, the humidity level, the lighting system, the air composition, the entertainment system, or the shade system.

8 The BMS of claim 1, wherein the signal includes a text string; and 63 wherein the one or more memory devices are further configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: parse the text string and extract a code blue identifier and a room identifier; determine an active code blue event is occurring based on the code blue identifier; determine a room location where the code blue event is occurring based on the room identifier; and adjust at least one of the temperature, the pressure, the humidity level, the lighting system, the air composition, an entertainment system, or a shade system in the determined room location automatically in response to determine that the active code blue event is occurring.

9. The BMS of claim 1, wherein the one or more memory devices are further configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: automatically communicate with a code blue team in response to the received signal; or automatically provide wayfmding directions to the code blue team member via a companion system.

10. An integration engine of a building management system, the integration engine comprising: one or more processing circuits located on-premises and comprising one or more memory devices coupled to one or more processors, the one or more memory devices configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: receive nurse call information from a nurse call system; determine a code blue identifier based on the nurse call information; determine a room identifier based on the nurse call information; determine that an active code blue event is occurring based on the code blue identifier; determine a room location where the active code blue event is occurring based on the room identifier; 64 initiate a code blue event response; and automatically implement a set of code blue actions in response to initiating the code blue event response directly without control of any off-premises processing circuits, the set of code blue actions including controlling at least one of a room heating ventilation, and air conditioning (HVAC) system or a lighting system.

11. The integration engine of claim 10, wherein the one or more memory devices are further configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: automatically control the HVAC system to lower a temperature of the room location in response to initiating the code blue event response.

12. The integration engine of claim 10, wherein the nurse call information includes a text string; and wherein the one or more memory devices are further configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: parse the text string and determine the code blue identifier and the room identifier based on the text string.

13. The integration engine of claim 10, wherein the one or more memory devices are further configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: automatically communicate with a code blue team in response to initiating the code blue event response.

14. The integration engine of claim 11, wherein the one or more memory devices are further configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: automatically provide location information including a location of a crash cart to a code blue team in response to initiating the code blue event response. 65

15. The integration engine of claim 10, wherein the one or more memory devices are further configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: automatically provide wayfmding information to a code blue team in response to initiating the code blue event response.

16. The integration engine of claim 10, wherein the one or more memory devices are further configured to store instructions thereon that, when executed by the one or more processors, cause the one or more processors to: automatically implement the set of code blue actions in response to initiating the code blue event response, the set of code blue actions including controlling at least one of a patient engagement system or a AV distribution system.

17. A method of operating an integration engine, the method comprising: receiving nurse call information indicating a code blue event is occurring in a healthcare facility; and adjusting at least one of a temperature, pressure, or humidity level in the healthcare facility automatically in response to the nurse call information.

18. The method of claim 17, further comprising: receiving the nurse call information from a nurse call system; determining a code blue identifier based on the nurse call information; determining a room identifier based on the nurse call information; determining that the code blue event is occurring based on the code blue identifier; determining a room location where the active code blue event is occurring based on the room identifier; initiating a code blue event response; and automatically implementing a set of code blue actions in response to initiating the code blue event response, the set of code blue actions including controlling at least one of a room heating ventilation, and air conditioning (HVAC) system or a lighting system.

19. The method of claim 18, further comprising: 66 automatically implementing the set of code blue actions in response to initiating the code blue event response, the set of code blue actions including controlling at least one of a patient engagement system or a AV distribution system.

20. The method of claim 17, wherein the nurse call information includes a text string; and further comprising: parsing the text string and determining the code blue identifier and the room identifier based on the text string.

21. The method of claim 17, further comprising: automatically communicating with a code blue team member via a companion system; and automatically providing wayfmding directions to a code blue team member via the companion system. 67