阅读说明：本技术 用于确定和可视化医疗装置资源可用性的系统和方法 (System and method for determining and visualizing medical device resource availability ) 是由 A·戴 J·R·特里 S·D·胡尔 M·格鲁姆 Y·法胡里 G·萨哈里亚 G·迪瓦恩 于 2021-04-12 设计创作，主要内容包括：本发明提供了用于收集、聚合和可视化包括一个或多个医疗设施的医疗装置可用性的资源可用性信息的系统和方法。在一个示例中,一种方法包括接收与多个呼吸机相关联的实时数据；针对该多个呼吸机中的每个呼吸机,基于通气开始时间、通气停止时间、呼吸机类型和呼吸机位置中的一者或多者确定呼吸机状态,该通气开始时间、该通气停止时间、该呼吸机类型和该呼吸机位置中的该一者或多者是从该实时数据确定的；以及基于该呼吸机状态更新一个或多个资源可用性图形用户界面(GUI)。(The present invention provides systems and methods for collecting, aggregating, and visualizing resource availability information including the availability of medical devices at one or more medical facilities. In one example, a method includes receiving real-time data associated with a plurality of ventilators; for each ventilator of the plurality of ventilators, determining a ventilator state based on one or more of a ventilation start time, a ventilation stop time, a ventilator type, and a ventilator position, the one or more of the ventilation start time, the ventilation stop time, the ventilator type, and the ventilator position determined from the real-time data; and updating one or more resource availability Graphical User Interfaces (GUIs) based on the ventilator status.)

1. A method, comprising:

receiving real-time data associated with a plurality of ventilators;

for each ventilator of the plurality of ventilators, determining a ventilator state based on one or more of a ventilation start time, a ventilation stop time, a ventilator type, and a ventilator position, the one or more of a ventilation start time, a ventilation stop time, a ventilator type, and a ventilator position determined from the real-time data; and

updating one or more resource availability Graphical User Interfaces (GUIs) based on the ventilator status.

2. The method of claim 1, wherein determining the ventilator state comprises determining:

a) whether a ventilation start time has been indicated;

b) whether ventilatory arrest time has not been indicated;

c) whether a ventilation start time has been indicated after a ventilation stop time; and

d) whether the ventilator is an invasive ventilator; and

for a respective ventilator, if one of a), d), and b) or c) is true, indicating that the ventilator state is in use and that the ventilator is an invasive ventilator.

3. The method of claim 1, wherein receiving real-time data associated with a plurality of ventilators comprises receiving real-time data from the plurality of ventilators or from one or more electronic medical records databases, and wherein updating the one or more resource availability GUIs based on the ventilator status comprises updating a ventilator occupancy displayed on the one or more resource availability GUIs.

4. The method of claim 3, further comprising displaying, via the one or more resource availability GUIs, a graphical representation of the ventilator occupancy configured to change visual appearance in response to the ventilator occupancy increasing above a threshold rate.

5. The method of claim 1, wherein receiving real-time data associated with a plurality of ventilators comprises receiving real-time data from a plurality of ventilators located at a plurality of different medical facilities.

6. The method of claim 1, wherein receiving real-time data associated with a plurality of ventilators comprises receiving an HL7 message.

7. The method of claim 1, wherein the one or more resource availability GUIs comprise a first resource availability GUI configured to display resource availability at a country level, a region level, and a facility level in a hospital network.

8. The method of claim 1, wherein the one or more resource availability GUIs comprises a second resource availability GUI configured to display resource availability at a national level, regional level, and facility level across multiple hospital networks and/or multiple individual hospitals.

9. The method of claim 1, wherein the one or more resource availability GUIs include a third resource availability GUI configured to display resource availability and patient load for a particular disease across one or more hospitals.

10. The method of claim 9, wherein the particular disease is codv-19, and wherein the third resource availability GUI is configured to display a count of patients undergoing a codv-19 test, a count of patients determined to be codv-19 positive, and a count of patients determined to be still under investigation for codv-19.

11. The method of claim 1, wherein the resource availability includes a ventilator count and/or ventilator occupancy in use, each ventilator count and/or ventilator occupancy in use updated based on the ventilator status, and the resource availability further includes a count of occupied beds, a count of frozen beds, a count of unoccupied beds, and a count of negative pressure beds for each patient room of a plurality of medical facilities.

12. A system, comprising:

a display; and

a computing device operably coupled to the display and storing instructions executable to:

receiving real-time data associated with a plurality of ventilators;

for each ventilator of the plurality of ventilators, determining whether the ventilator is currently in use based on the real-time data;

outputting, to the display, a Graphical User Interface (GUI) including respective ventilator occupancy rates for hospital wards, hospitals, hospital networks, states, regions, and/or countries, each ventilator occupancy rate determined based on a number of ventilators determined to be currently in use and a location of each ventilator.

13. The system of claim 12, wherein to determine whether a ventilator is currently in use, the instructions are executable to determine:

a) whether a ventilation start time of the ventilator has been indicated;

b) whether a ventilatory arrest time of the ventilator has not been indicated; and

c) whether a ventilation start time of the ventilator has been indicated after a ventilation stop time;

and wherein if one of a), and b) or c) is true, the instructions are further executable to determine that the ventilator is currently in use.

14. The system of claim 12, wherein the instructions are executable to determine a location of each ventilator based on the real-time data.

15. The system of claim 12, wherein the instructions are executable to update each respective ventilator occupancy in real-time as the real-time data is received.

16. The system of claim 12, wherein the GUI further comprises respective bed occupancy for one or more hospital wards, one or more hospitals, one or more hospital networks, one or more states, one or more regions, and/or one or more countries.

17. The system of claim 12, wherein the GUI is configured to display a resource availability alert in response to determining that the ventilator occupancy and/or bed occupancy is above a respective threshold level.

18. A method, comprising:

receiving real-time data associated with a plurality of ventilators;

for each ventilator of the plurality of ventilators, determining whether the ventilator is currently in use in a defined geographic area based on the real-time data; and

outputting, to the display, a Graphical User Interface (GUI) including a ventilator occupancy for the defined geographic area, the ventilator occupancy for the defined geographic area determined based on whether each ventilator is currently being used in the defined geographic area.

19. The method of claim 18, wherein the determining comprises determining, for each ventilator:

a) whether a ventilation start time has been indicated;

b) whether ventilatory arrest time has not been indicated;

c) whether a ventilation start time has been indicated after a ventilation stop time; and

d) whether the ventilator is located in the defined geographic area; and is

For a respective ventilator, if one of a), d), and b) or c) is true, the method includes indicating that the ventilator is currently in use in the defined geographic area.

20. The method of claim 18, further comprising displaying, via the GUI, a graphical representation of the ventilator occupancy configured to change visual appearance in response to the ventilator occupancy increasing above a threshold rate.

Technical Field

Embodiments of the subject matter disclosed herein relate to resource management on hospital networks, and in particular, to displaying available resources between wards, facilities, regions, etc. for allocation purposes in the absence of an out-of-expectation situation using computerized tools.

Background

Emergency care of patients in a hospital or other medical facility may include the use of resources such as medical devices, Intensive Care Unit (ICU) beds, and the like. Hospitals may reserve sufficient resources to care for a desired number of patients that may peak due to seasonal influenza epidemics or other desired events that result in a temporary surge in hospital admissions. However, if an unexpected number of patients are admitted, in particular if a plurality of patients are admitted for the same condition and therefore require the same hospital resources, the hospital resources may not be met or even become unavailable.

Disclosure of Invention

In one embodiment, a method includes receiving real-time data associated with a plurality of ventilators; for each ventilator of the plurality of ventilators, determining a ventilator state based on one or more of a ventilation start time, a ventilation stop time, a ventilator type, and a ventilator position, the one or more of the ventilation start time, the ventilation stop time, the ventilator type, and the ventilator position determined from the real-time data; and updating one or more resource availability Graphical User Interfaces (GUIs) based on the ventilator state.

It should be appreciated that the brief description above is provided to introduce in simplified form a selection of concepts that are further described in the detailed description. It is not meant to identify key or essential features of the claimed subject matter, the scope of which is defined uniquely by the claims that follow the detailed description. Furthermore, the claimed subject matter is not limited to implementations that solve any disadvantages noted above or in any part of this disclosure.

Drawings

The invention will be better understood by reading the following description of non-limiting embodiments with reference to the attached drawings, in which:

FIG. 1 schematically illustrates an exemplary collaborative resource utilization system.

FIG. 2 schematically illustrates another example collaborative resource utilization system.

FIG. 3 schematically illustrates another example collaborative resource utilization system.

FIG. 4 schematically illustrates one or more data feed types generated by a facility for determining resource utilization.

Fig. 5 schematically shows a plurality of data feeds generated by a facility for determining resource utilization.

FIG. 6A is a flow diagram illustrating an exemplary method for generating a data feed used by a collaborative resource utilization system to generate a national capacity Graphical User Interface (GUI), according to a first embodiment.

FIG. 6B is a flow diagram illustrating an exemplary method for generating a data feed used by the collaborative resource utilization system to generate a national capacity GUI according to a second embodiment.

FIG. 7A is a flow diagram illustrating an exemplary method for generating a data feed used by a collaborative resource utilization system to generate a key resource GUI according to a first embodiment.

FIG. 7B is a flow diagram illustrating an exemplary method for generating a data feed used by the collaborative resource utilization system to generate a key resource GUI according to a second embodiment.

FIG. 8 is a flow diagram illustrating an exemplary method for generating a data feed used by the collaborative resource utilization system to generate an infectious disease GUI, according to a first embodiment.

FIG. 9 is a schematic diagram illustrating an exemplary flat file feed of data feeds provided to resource utilization servers of a collaborative resource utilization system.

Fig. 10 is a flow chart illustrating an exemplary method for determining a state of a ventilator.

Fig. 11A is a flow chart illustrating an exemplary method for determining a disease state of a patient.

Fig. 11B is an exemplary table that may be accessed to determine a patient's disease status for a patient who has tested positive for the disease at least once.

Fig. 11C is an exemplary table that may be accessed to determine a patient disease status for a patient for which the disease has not tested positive.

FIG. 12 is a flow diagram illustrating an exemplary method for generating user interface data for a national capacity GUI.

FIG. 13 is a flow diagram illustrating an exemplary method for generating user interface data for a key resource GUI.

FIG. 14 is a flow chart illustrating an exemplary method for generating user interface data for an infectious disease GUI.

FIG. 15 illustrates an exemplary GUI displaying resource availability at a national level within a hospital network.

FIG. 16 illustrates an exemplary view of the GUI of FIG. 15 for filtering hospital resources by type.

FIG. 17 illustrates an exemplary view of the GUI of FIG. 15 displaying resource availability at a regional level within a hospital network.

FIG. 18 illustrates an exemplary view of the GUI of FIG. 15 displaying resource availability at a regional level within a hospital network, wherein additional data is displayed via a pop-up display panel.

FIG. 19 shows an exemplary view of the GUI of FIG. 15 displaying facility-level resource availability within a hospital network.

FIG. 20 illustrates an exemplary view of the GUI of FIG. 15 displaying facility-level resource availability within the hospital network, wherein additional data is displayed via a pop-up display panel.

Fig. 21 illustrates an exemplary view of the GUI of fig. 15 displaying ward-level resource availability within a facility within a hospital network.

Fig. 22-25 illustrate example GUIs displaying resource availability within hospital networks at different geographic ranges.

Fig. 26-27 show exemplary views of the GUI of fig. 22 displaying resource availability within a hospital network, wherein filtering and sorting options may be selected via a settings panel.

FIG. 28 illustrates an exemplary view of the GUI of FIG. 22 displaying resource availability within a hospital network, wherein the display of resources has been ordered based on resource availability.

FIG. 29 illustrates an exemplary GUI displaying resource utilization within a hospital via a customized modular layout.

Fig. 30-32 show exemplary views of the GUI of fig. 29 displaying resource utilization within a hospital, with additional data displayed via a pop-up display panel.

Fig. 33 shows an exemplary view of the GUI of fig. 29 displaying a projection of patient activity within a hospital system.

Fig. 34-35 show exemplary views of the GUI of fig. 29 displaying resource utilization within a hospital, wherein customization options may be selected via a settings panel.

FIG. 36 illustrates an exemplary view of the GUI of FIG. 29 displaying resource utilization within a hospital, wherein information can be viewed via a legend panel.

Fig. 37-44 show exemplary views of a country capacity GUI according to another embodiment of the present disclosure.

Detailed Description

A healthcare facility may be equipped to handle an expected volume of patients, with available additional resources being reserved to provide emergency capacity for unexpected events beyond which the expected volume of patients needs care. However, certain situations such as an infectious disease outbreak may put pressure on the healthcare system, which often requires more resources than the facility is equipped to provide, even in view of the resources that may be reserved. Thus, medical facilities across cities, states, regions, and even entire countries and other countries may gather and share resource availability data to enable healthcare institutions, such as hospital administrators, government agencies, etc., to make decisions regarding sharing/allocating available resources, ordering new equipment, hiring additional healthcare personnel, etc. However, collecting resource availability data can be time consuming and require personnel time, which can put stress on the healthcare system. For example, many medical facilities may not have an appropriate centralized system to track how many critical medical resources (such as ventilators) are currently in use, scheduled to be used, in maintenance, etc., so one may manually determine ventilator usage by visually inspecting each room of each ward/ward of the medical facility, which is time consuming and error prone. Furthermore, when relying on standard methods to collect resource availability data, it can be challenging to keep the resource availability data up-to-date. Thus, when making decisions about how to allocate resources across multiple medical facilities, when to request additional resources, etc., these decisions may be made based on incomplete or outdated information, which may result in a lack of resources for some facilities, while other facilities may have a large amount of resources, which may ultimately compromise patient care.

Thus, according to embodiments disclosed herein, current resource availability data may be collected from a plurality of medical facilities and aggregated automatically, in real-time, or near real-time. The aggregated data may be visualized via one or more graphical user interfaces that may indicate key resource availability (e.g., bed availability, ventilator availability) and infectious disease information (e.g., number of positive cases, number of investigated patients) on a ward, hospital network, state, regional, and/or national basis. The resource availability data and infectious disease information may be automatically updated as resource availability changes and/or as disease test results are available. In doing so, the healthcare facility may be immediately informed of resource availability information about multiple healthcare facilities, while also being informed of outbreaks, which may enable the healthcare facility to make informed decisions about resource allocation based on up-to-date information via one or more graphical user interfaces that may present a limited set of information (e.g., critical resource availability, location/region based disease status) to the user/healthcare facility. In this way, the user's interaction with the available data may be made more efficient, as the user is not forced to sift through multiple separate data feeds, data files, etc., to identify the desired information, and then aggregate the desired information.

FIG. 1 schematically illustrates an exemplary collaborative resource utilization system 100 that may be implemented across multiple medical facilities, such as hospitals. The collaborative resource utilization system 100 may include a resource utilization server system 102. Server system 102 may include resources (e.g., memory 114, processor 112) that may be allocated to store and execute one or more resource dashboards. For example, as shown in FIG. 1, the dashboard 104 is stored on the server system 102 of the first hospital (Hospital 1); a plurality of additional dashboards may be stored on the server system 102, each additional dashboard corresponding to a respective hospital (hospital 2 up to hospital N).

As will be explained in more detail below, each dashboard may indicate resource utilization and availability for each hospital. For example, each dashboard may track the total number of hospital beds, total occupied hospital beds, total and occupied hospital beds by bed type (e.g., ICU, disease progression care ward, observation care, negative pressure, etc.), and total and utilized medical devices, such as ventilators, for the corresponding hospital. In addition, data from one or more hospital-specific dashboards can be combined to generate hospital web dashboards, regional hospital dashboards, national hospital dashboards, and the like, in order to track/indicate resource utilization across multiple hospitals, regions, and even national ranges. When requested, the dashboard may be output for display on a display device as one or more graphical user interfaces, as described below. As used herein, a dashboard may include data regarding resource utilization for a ward, hospital network, hospital within a particular region, and/or hospital within a national range. The dashboard may include data that may be presented as one or more of the graphical user interfaces described in more detail below. The dashboard may not have any particular visual appearance and may include data aggregated from one or more hospitals that is updated as new data is received.

The server system 102 may be communicatively coupled to a plurality of hospitals 118, from a first hospital (hospital 1), a second hospital (hospital 2), through to an nth hospital (hospital N), via a network 116. Each hospital may be configured to send resource utilization information to the server system 102. The resource utilization information may include information tracked via the aforementioned dashboard, such as hospital bed utilization and medical device utilization.

To collect and transmit resource utilization information to the server system 102, each hospital may include various systems and devices to track patient admissions, patient bed assignments, medical device deployments, patient condition information (e.g., confirmed patient conditions, suspected patient conditions, patient laboratory results, etc.), etc., in real-time, and transmit the tracked information to the server system 102. Fig. 1 illustrates an example of hospital systems and apparatus for a first hospital that may be used to collect hospital resource utilization information, transmit the collected hospital resource utilization information to the server system 102, and/or view one or more dashboards generated by the server system 102. It should be understood that the hospital systems and devices described herein are exemplary and that other systems and/or devices may be used to collect and transmit hospital resource utilization information without departing from the scope of the present disclosure. Further, while a hospital is described herein, other medical facilities may transmit resource utilization information to the server system 102, such as outpatient clinics, local or regional health regulatory agencies, other governmental agencies, and so forth.

Hospital 1 may include a hospital operating system 128. The hospital operating system 128 may store and/or control a variety of hospital-related, caregiver-related, and patient-related information, including, but not limited to, patient admission information (including the patient's date of admission and location within the medical facility), medical device information (e.g., total number of each type of medical device, current status of each medical device, etc.), patient care plans and workflows, and caregiver information (including which care providers are monitoring/treating which patients). Further, the hospital operating system 128 is communicatively coupled to the plurality of medical devices 120, the Electronic Medical Records (EMR) database 122 (described in more detail below), and the one or more workstations 124.

The medical devices 120 may include medical devices (such as ventilators, anesthesia machines, infusion pumps, pulse oximeters, heart rate monitors, blood glucose monitors, ECGs, etc.) configured to monitor and/or provide medical treatment to respective patients, as well as microphones, cameras, and other devices. The medical device 120 may send the output to the hospital operating system 128, the EMR database 122, and/or one or more caregiver devices. Further, in some examples, the hospital operating system 128 and/or the EMR database 122 can receive diagnostic imaging information obtained from one or more imaging modalities (such as ultrasound, CAT, MRI, X-ray, etc.). Based on the information output from the medical devices 120, the hospital operating system 128 and/or the EMR database 122 may track the current utilization of each medical device. In some examples, data from one or more medical devices may be sent directly to the server system 102.

The hospital operating system 128 may track hospital bed usage. For example, when a patient is admitted, the hospital operating system 128 may associate the patient with an identifier (e.g., identification code) and track patient status, patient ward/ward assignments, patient bed assignments, and the like. The hospital operating system 128 may also track confirmed and/or suspected patient conditions. For example, the hospital operating system 128 may receive laboratory results from a laboratory service and update the diagnosed patient condition in response to the received laboratory results and/or information provided by the care provider for each patient. In some examples, the EMR database 122 may additionally or alternatively track confirmed and/or suspected patient conditions based on information provided by the provider, laboratory results, and/or other information.

The EMR database 122 may be an external database, or the EMR database 122 may be a local database (e.g., housed on a hospital's device). The EMR database 122 may be a database stored in a mass storage device configured to communicate with secure channels (e.g., HTTPS and TLS) and store data in encrypted form. Further, the EMR mass storage device is configured to control access to the patient electronic medical records such that only authorized healthcare providers can edit and access the electronic medical records. The patient's EMR may include patient demographic information, family medical history, past medical history, lifestyle information, existing medical conditions, current medications, allergies, surgical history, past medical screening and procedures, past hospitalizations and visits, and the like.

The hospital 1 also includes one or more workstations 124. Each workstation may include a processor, memory, communication module, user input device, display (e.g., screen or monitor), and/or other subsystems and may be in the form of a desktop computing device, laptop computing device, tablet, smart phone, or other device. The workstation may be located locally at the hospital (such as part of hospital administration) and/or remotely from the hospital (such as the user's mobile device).

The hospital operating system 128, medical devices 120, EMR database 122, and workstation 124 may communicate with one another via a hospital network, which may be a suitable wired and/or wireless network. Communication between the systems/devices of hospital 1 and server system 102 may be provided by a suitable device, here, an edge device 126. The edge device 126 may illustratively be an edge processing device, a cloud processing device, or an internetworking gateway. The border device 126 may facilitate a secure communication link between the system/device over the hospital network and the server, processor, and computer-readable medium communications that implement the server system 102.

The server system 102 includes a communication module 110, a memoryA memory 114 and a processor 112 to generate and store the dashboards described herein. The communication module 110 facilitates the transfer of electronic data within and/or between one or more systems. Communications via the communication module 110 may be implemented using one or more protocols. In some examples, communications via the communication module 110 occur in accordance with one or more standards (e.g., digital imaging and communications in medicine (DICOM), health grade seven (HL7), ANSI X12N, etc.). The communication module 110 may be a wired interface (e.g., a data bus, a Universal Serial Bus (USB) connection, etc.) and/or a wireless interface (e.g., radio frequency, infrared, Near Field Communication (NFC), etc.). For example, the communication module 110 may use any past, present, or future communication protocol (e.g., BLUETOOTH) via a wired Local Area Network (LAN), wireless LAN, Wide Area Network (WAN), or the like^TMUSB 2.0, USB 3.0, etc.).

The memory 114 includes one or more data storage structures, such as optical, magnetic, or solid-state memory devices, for storing programs and routines executed by the processor 112 to implement the various functions disclosed herein. The memory 114 may include any desired type of volatile and/or non-volatile memory, such as, for example, Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), flash memory, Read Only Memory (ROM), and the like. Processor 112 may be, for example, any suitable processor, processing unit or microprocessor. The processor 112 may be a multi-processor system and, thus, may include one or more additional processors that are identical or similar to each other and that are communicatively coupled via an interconnection bus.

As used herein, the terms "sensor," "system," "unit," or "module" may include hardware and/or software systems that operate to perform one or more functions. For example, a sensor, module, unit, or system may include a computer processor, controller, or other logic-based device that performs operations based on instructions stored on a tangible and non-transitory computer-readable storage medium (such as a computer memory). Alternatively, a sensor, module, unit or system may comprise a hardwired device that performs operations based on hardwired logic of the device. The various modules or units illustrated in the figures may represent hardware that operates based on software or hardwired instructions, software that instructs the hardware to perform operations, or a combination thereof.

A "system," "unit," "sensor," or "module" may include or represent hardware and associated instructions (e.g., software stored on a tangible and non-transitory computer-readable storage medium such as a computer hard drive, ROM, RAM, etc.) to perform one or more operations described herein. Hardware may include electronic circuitry that includes and/or is connected to one or more logic-based devices, such as microprocessors, processors, controllers, and the like. These devices may be off-the-shelf devices that are suitably programmed or instructed to perform the operations described herein in accordance with the instructions described above. Additionally or alternatively, one or more of the devices may be hardwired with logic circuitry to perform these operations.

One or more of the devices described herein may be implemented through a cloud or other computer network. For example, although server system 102 is shown in fig. 1 as constituting a single entity, it should be understood that server system 102 may be distributed across multiple devices, such as across multiple servers.

The collaborative resource utilization system 100 may likewise include a client device 130 that includes a display on which a user may view data from the collaborative resource utilization system. For example, data from the dashboard 104 may be displayed on the client device 130 as a graphical user interface 132, allowing a user to view resources available at a given hospital N. In addition, data from other dashboards, such as aggregated data from multiple hospitals in a hospital network, may be displayed within a graphical user interface on the client device 130, which may allow a user to visualize and navigate between data stored in different dashboards. The graphical user interface 132 may also allow the user to further interact with data included on the dashboard, as shown in fig. 15-36.

The client device 130 may include user input devices, memory, processors, and communication modules/interfaces similar to the communication module 110, memory 114, and processor 112 described above, and thus the description of the communication module 110, memory 114, and processor 112 is equally applicable to the other devices described herein. The user input device may include a keyboard, mouse, touch screen, microphone, or other suitable device.

As one example, the client device may store one or more graphical user interface templates in memory that include placeholders for relevant information stored on the server system 102. For example, the client device 130 may include a graphical user interface 132 that includes a template of a resource dashboard that a user of the client device may configure with placeholders for desired patient information. When the graphical user interface is displayed on the client device, relevant information can be retrieved from the server system 102 (e.g., from the dashboard) and inserted into the placeholder. In other examples, server system 102 may present the selected dashboard into a graphical user interface described herein and may send the graphical user interface for display on a display device (e.g., of client device 130) when requested.

As will be explained in more detail below, each hospital or other medical facility may be configured to send data to the server system 102 such that resource availability for hospital wards, hospitals, hospital networks, regions, and/or countries may be tracked and visualized through one or more resource availability graphical user interfaces, as described below. Resource availability may be updated in real-time or near real-time as data is received from each hospital. As used herein, real-time may include sending data as soon as it is collected, without intentional delay. Thus, once the hospital obtains resource availability information (e.g., the patient is permitted to obtain a particular bed of the hospital), the resource availability information is sent to the server system. As used herein, near real-time may indicate that data is periodically sent from a hospital to a server system to allow data aggregation, data filtering, and/or other data processing actions. However, near real-time transmission of data may still be fast relative to when the data is made available, such as transmitting the data within 1-5 minutes after the data is made available (e.g., rather than once the data is available).

Fig. 2 illustrates another exemplary collaborative resource utilization system 200 that may be implemented across various healthcare facilities (e.g., hospitals) and hospital systems within various geographically-layered regions. The collaborative resource utilization system 200 includes a resource utilization server 202 that includes a plurality of modules for: the method includes receiving a plurality of data feeds from a plurality of facilities, evaluating resource utilization at each facility in real-time or near real-time, and generating a plurality of graphical user interface tiles configurable based on one or more of a user query, the data feeds received from the facilities, and a facility type. The resource utilization server 202 may be similar to the resource utilization server system 102 and, thus, may include similar components in addition to the modules described herein at fig. 2, including the communication module 110, the processor 112, and the non-transitory memory 114.

The collaborative resource utilization system 200 is shown to include a state system 270 that includes an in-state hospital system 260 and facilities 250. It should be understood that the state system 270 may include multiple hospital systems and/or multiple facilities, depending on population, area, location, etc. While the present example is shown with respect to resource utilization by states, it should be understood that the collaborative resource utilization system 200 may be implemented for regions comprising multiple states, countries comprising multiple regions, and internationally across multiple countries.

The hospital system 260 is shown as including facilities 230 and 240, but it should be understood that the hospital system may include fewer or more facilities.

Each of the facilities 230, 240, and 250 may include a respective healthcare command center 232, 242, and 250 for coordinating patient care and resources within the respective facility and/or across the respective hospital system. Each of the facilities 230, 240, and 250 also includes a respective data processing center 236, 246, and 256 for performing various data-related operations, including collecting, storing, processing, distributing, and/or allowing access to large amounts of data. While this example shows each facility including a data center, other configurations, such as a data center located outside of the facility, are possible. In some examples, two or more facilities within a hospital system may share a data center. Further, data centers 236, 246, and 256 may be configured as local data centers, cloud-based data centers, or a combination thereof. Each of the facilities 230, 240, and 250 also includes a workstation 234, 244, and 254. Each facility may include a plurality of workstations. The workstation may be a command center workstation, a medical device workstation, or any other type of workstation for accessing and/or updating one or more of patient information and hospital resource information, including critical resource information.

In one embodiment, as shown herein at fig. 2, hospital systems and facilities within a state system may form part of the data sharing hospital network system 210. Thus, hospital data centers 236, 246, and 256 may be equipped to include respective virtual machine systems 238, 248, and 258 for obtaining a plurality of data from one or more of the respective hospital data centers, command centers, and workstations, processing the received data, and transmitting the data to resource utilization server 202. Exemplary data feeds from the virtual machine systems 238, 248, and 258 to the resource utilization server 202 are indicated at 220. While this example shows each facility configured with a virtual machine system, it should be understood that the virtual machine system may be configured based on the location and type of the respective facility and the data center of the hospital system. The data feed 220 from the facilities 230, 240, and 250 to the resource utilization server 202 via the respective virtual machine systems 238, 248, and 258 may include one or more of a flat file data feed and an HL7 data feed, as described further below.

Further, the resource utilization server 202 can deliver one or more resource utilization dashboards, such as dashboard 104, to requesting workstations, including display devices within a facility (e.g., command center workstations, medical device workstations, etc.), and/or to any requesting client devices, such as the client devices described in fig. 1. Communication from one or more resource utilization dashboards of the resource utilization server is indicated by 222. As described above, when requested, the dashboard may be output for display on a respective display device of the workstation via a Graphical User Interface (GUI). The one or more resource utilization dashboards can include a hospital system infectious disease dashboard, a key resource dashboard, and a national capacity dashboard. Fig. 29-34 show and describe corresponding graphical user interfaces (including a hospital system infectious disease user interface), fig. 16-21 show and describe a key resource user interface, and fig. 22-28 and 36-44 show and describe a national capacity user interface.

Virtual machine systems 238, 248, and 258 may include multiple virtual machines including one or more processing units and non-transitory memory. Further, the virtual machine system may allow access to hospital data for authorized personnel via a secure connection (such as a VPN). Although the present example of fig. 2 describes data transfer to the resource utilization server 202 via a virtual machine system provided in a hospital data center, fig. 3 shows another embodiment of a cooperative resource utilization system that does not implement virtual machines.

Turning to fig. 3, another exemplary resource utilization system 300 for a non-data sharing hospital network system 310 is shown. The hospital network system 310 includes facilities 330 and 340 that form part of a hospital system 360. The network system 310 also includes a facility 350, and the facilities 330, 340, and 350 form part of a state system 370.

Similar to the facilities discussed in fig. 2, each of the facilities 330, 340, and 350 includes a respective command center 332, 342, and 352, a respective data center 336, 346, and 356, and a respective workstation 334, 344, and 354. The resource utilization server 202 may receive a plurality of data from each of the facilities 330, 340, and 350 via one or more of a workstation, a command center, a client device, and a data center. The data feed 320 from the facilities 330, 340, and 350 may be a flat file data field that does not include fully identified patient data. Details of providing the flat file data fields to the resource utilization server for use in generating the resource utilization dashboard are described further below.

In response to receiving the data feed from the respective facility, the resource utilization server 202 can generate and update one or more resource utilization dashboards and transmit the one or more dashboards to the requesting workstation and/or client device (including the command center workstation, the medical device workstation, and the data center).

Next, FIG. 4 illustrates a schematic diagram of an exemplary resource utilization system 400 that illustrates resource utilization data transfer between the facility 420 and the resource utilization server 202. The facility 420 is a healthcare facility, such as a hospital, and is similar to the facility discussed in fig. 2 and 3, and thus may include similar components to those described in fig. 2 and 3. Briefly, facility 420 includes a hospital data center 426 that includes one or more hospital databases 450. Further, facility 420 may include a plurality of patient rooms, each including a plurality of rooms (not shown). In addition, each room may include one or more beds (not shown). The facility 420 may also include a workstation 424 (which may be an EMR workstation, a workstation 434 communicatively coupled to the medical device 430, and a workstation 444 in the healthcare command center 422). Other types of workstations within a facility for one or more of patient health management and resource utilization, including critical resource utilization, are also within the scope of the present disclosure.

Further, the hospital data center 426 may be equipped with a virtual machine system 428 that includes multiple server systems for accessing and transmitting data feeds from the hospital database 450 and one or more of the workstations 424, 434, and 444.

In one embodiment, one or more of patient data (such as infectious disease data), hospital resource utilization data (such as key resource utilization data), and hospital resource inventory data (such as key resource inventory data) are transmitted to resource utilization server 202 via one or more of HL7 data feed 482 and flat file data feed 480, via virtual machine system 428 provisioned within hospital data center 426. For example, EMR data may be transmitted via an HL7 data feed. The HL7 data can be one or more of full identification data and filtered data (without patient identification information). The flat file data feed 480 may include designated fields and corresponding data extracted from EMRs, key resources, and infectious disease data related to patients and resources within the facility 420. Fig. 9 illustrates exemplary flat file fields. Further, fig. 6A, 7A, and 8 further describe the details of generating and transmitting the flat file below.

While the above exemplary embodiment describes the flat file data being transferred via a virtual machine system, in another embodiment, the flat file data may be transferred without utilizing virtual machine system 428. The transmission of the flat file data feed is shown in dotted lines. For example, the flat file data feed 478 may be generated and transmitted by the hospital data center 426 via one or more data center processors. In another example, one or more workstations (including workstations 424 and 434) may process and transmit the flat file data 470 and 472 to the resource utilization server 202. The flat file transfer may be via a suitable file transfer protocol such as Secure File Transfer Protocol (SFTP).

The resource utilization server 202 can receive a plurality of data feeds from a facility via the virtual machine system 428, the data center 426, and one or more of the plurality of workstations 424, 434, and 444. The resource utilization server 202 may process the data and generate user interface data that may be transmitted to one or more of the hospital data center 426 and the healthcare command center 422, as indicated by 474 and 476. The processing of the plurality of data feeds may be performed by one or more of a hospital system infectious disease module, a key resources module, and a national capacity module, and may be performed automatically and/or based on client requests. The user interface data may then be presented via a graphical user interface on a display portion of a client device, which may be one or more of workstations 424, 434, and 444, or any suitable client display device.

FIG. 5 is a schematic illustration of a plurality of data feeds transmitted via virtual machine system 428 for resource utilization system 400 (shown in FIG. 4). As discussed in fig. 4, the plurality of data feeds to resource utilization server 202 may include HL7 data feed 482 from an Electronic Medical Records (EMR) system of facility 420, and flat file data feed 480.

In particular, the hospital system infectious disease module 204 may receive an occupancy data feed 484, a ventilator inventory and usage data feed 485, an infectious disease data feed 486, and an ADT _ ORU _ ORM data feed 487. In one example, the occupancy data feed 484 may include a bed major template flat file data feed (including bed inventory data for the facility 420) and a bed block flat file data feed (including bed usage data for the facility 420). The ventilator inventory and usage data feed 485 may include a ventilator inventory flat file data feed and a ventilator usage flat file data feed, where the ventilator usage flat file data feed may be generated based on ventilator usage data obtained by the method 1000 described in fig. 10. The infectious disease data feeds 486 may include a investigated Patient (PUI) data feed and an infected patient data feed, wherein the PUI data and infected patient data may be obtained based on the method 1100 described in fig. 11.

The ADT _ ORU _ ORM data feed 487 is the HL7 data feed, and can include admission, discharge, and transfer (ADT) data feeds, order entry message (ORM) data feeds (including infectious disease laboratory orders, ventilator application orders, and suspension orders), and Observation (ORU) data feeds (including infectious disease test results, ventilator usage data, such as start time, stop time, type, identifier). In one example, the ADT _ ORU _ ORM data feed 487 is a fully identified patient data feed, including patient information (e.g., patient name) and patient demographic information. In another example, the ADT _ ORU _ ORM data feed 487 is a data feed without fully identified patient data, where the fully identified patient data is not provided to the server. In this case, personal and demographic information of the patient may not be provided. Further, in one embodiment, the fully identified data feed and the data feed without fully identified information may be filtered by, for example, a hospital data center processor to extract specific data for one or more of a critical resource and an infectious disease, and the extracted data may be provided to the resource server 202 via the virtual machine system. In this way, by generating a particular data feed for one or more of a critical resource and an infectious disease, processing of the data feed is accelerated, and user interface data can be generated and updated in real-time or near real-time.

The infectious disease module 204 may process the received data feeds 484, 485, 486, and 487 and generate infectious disease user interface data. The infectious disease user interface data may be presented in an infectious disease Graphical User Interface (GUI) at one or more workstations and client devices associated with the facility. An exemplary infectious disease GUI is shown and described in fig. 29-34. Briefly, for each facility and/or for a hospital system including one or more facilities, the generated infectious disease user interface data may include patient load data, status data of CC and Cardiovascular (CV) specific bed occupancy at intensive care (CC) and CV wards, patient testing and observation activities regarding infectious diseases, various environmental services (EVS) data of CC and CV beds, ventilator usage regarding individual patients, and bed occupancy regarding infectious disease patients. In this way, the infectious disease module and infectious disease GUI may provide system-level and/or facility-level key resource utilization (including critical illness, ventilators) and patient information in real-time or near real-time during endemic, epidemic, and pandemic conditions affecting public health, to expedite decision making and improve resource utilization efficiency, enable real-time and near real-time demand assessment, and organize mobilization of key resources.

In addition, FIG. 29 to FIG. 34 show the COVID-19 infectious disease. It should be understood that the infectious disease module and infectious disease GUI may be implemented for any infectious and/or infectable disease or any disease or condition that causes public health problems (e.g., radioactive waste exposure, toxic gas exposure) and corresponding related critical care resource utilization.

The critical resources module 206 may receive an occupancy data feed 490, a critical resources inventory and usage data feed 491, and an ADT _ ORU _ ORM data feed 492. The occupancy data feeds 490 may include a bed major template flat file data feed (including bed inventory data for the facility 420) and a bed block flat file data feed (including bed usage data for the facility 420). The key resource inventory and usage data feeds 491 may include one or more key resource inventory flat file data feeds and corresponding one or more key resource usage flat file data feeds. In one example, the key resource may include a ventilator, and thus, a ventilator usage profile data feed may be generated based on ventilator usage data obtained by the method 1000 described in fig. 10. Thus, in some examples, the key resource inventory and usage data feed 491 may include a ventilator inventory and usage data feed 495, which will be described below. The ADT _ ORU _ ORM data feed 492 is an HL7 data feed, and is similar to the ADT _ ORU _ ORM data feed 487 described above, except that the ORM data feed may not include laboratory orders and the ORU data feed may not include infectious disease outcomes. In other examples, the ADT _ ORU _ ORM data feed 492 may include only ADT data feeds (e.g., including admissions, discharges, and transfers), and may not include ORM or ORU feeds. Further, the ADT _ ORU _ ORM data feed may be a filtered data feed that may include data that is fully identified or data without fully identified patient information as described above. Other implementations in which the ADT _ ORU _ ORM data feed to the resource utilization server (i.e., to any of the modules 204, 206, and 208) is not filtered to extract specific resource utilization and/or infectious disease information are also within the scope of the present disclosure.

The key resource module 206 may process the received data feeds 490, 491, and 492 and generate key resource user interface data. For example, the critical resource user interface data may include critical resource usage data for critical care units (including ICU, PCU, MT/MS units, OBS units, negative pressure units) and ventilators of the facility. The key resource user interface data may be presented in a key resource Graphical User Interface (GUI) at one or more workstations and client devices associated with the facility. Fig. 22-28 illustrate and describe exemplary key resource GUIs.

In addition, the national capacity module 208 may receive an occupancy data feed 494, a ventilator inventory and usage data feed 495, and an infectious disease data feed 496. As described above, the occupancy data feed 494 may include a bed major template flat file data feed (including bed inventory data for the facility 420) and a bed blockage flat file data feed (including bed usage data for the facility 420). The ventilator inventory and usage data feed 495 comprises a ventilator inventory flat file data feed and a ventilator usage flat file data feed, wherein the ventilator usage flat file data feed may be generated based on ventilator usage data obtained by the method 1000 described in fig. 10. Additionally, as described above, the ventilator inventory and usage data feed 495 may be sent to/used by the critical resource module 206. The infectious disease data feeds 496 may include a subject under investigation (PUI) data feed and an infected patient data feed, where the PUI data and infected patient data may be obtained based on the method 1100 described in fig. 11A.

The country capacity module 208 may process the received data feeds 494, 495, and 496 and generate country capacity user interface data. The country capacity user interface data may be presented in a country capacity Graphical User Interface (GUI) at one or more workstations and client devices associated with the facility. Fig. 15-21 and 37-44 illustrate and describe exemplary country capacity GUIs.

In one example, the infectious disease module 204, the key resources module 206, and the national capacity module 208 may utilize only the flat file data feed and/or the filtered HL7 data feed to generate corresponding user interface data for the infectious disease GUI, the key resources GUI, and the national capacity GUI. In this way, real-time or near real-time data can be transmitted and processed to provide near real-time updates regarding key resources and infectious disease progression.

Although a single facility is shown here, it should be noted that the infectious disease module 204, the key resources module 206, and the national capacity module 208 may receive data from multiple facilities of various demographic scoring levels (e.g., hospital systems, states, regions, and countries). In one embodiment, when the number of facilities increases above a threshold and/or the processing time increases above a threshold, modules 204, 206, and 208 may generate user interface data for the respective GUI using only the flat file feed and/or the filtered HL7 data feed.

It should be understood that the resource utilization server 202 may receive some data via HL7 and other data via flat files, but within the same module (e.g., within the key resources module 206), the method of receiving a particular data element (e.g., such as bed inventory data for a given data element) that is received from all hospitals via HL7 or flat files is consistent across hospitals, rather than from one hospital via HL7 and another hospital via flat files for the same data element. However, between modules, whether a data element is received via HL7 or via a flat file, the situation may change.

In some embodiments, a resource utilization server, such as the resource utilization server system 202 discussed in fig. 2-5, and the resource utilization server 102 discussed in fig. 1 may be implemented by a virtual machine system comprising a plurality of virtual machines, wherein the virtual machine system is provisioned within a data center of a healthcare facility. Each of the plurality of virtual machines may be configured as a computing system including a memory and one or more processors.

Fig. 6A is a flow diagram illustrating a high-level method 600 of generating one or more data feeds for a national capacity module of the resource utilization server 202 (such as the national capacity module 208 of fig. 2-5), according to one embodiment of the present disclosure. In particular, the method 600 may be used to generate a flat file data feed for a national capacity module. For example, for an facility that is not part of the data sharing network, the method 600 may be implemented to generate a flat file feed with a specified feed that does not include fully identified patient information (exemplary fields are shown in fig. 9), and transmit the generated flat file data to a national capacity module of the resource utilization server.

Method 600 and other methods 650, 700, 750, and 800 described herein may be performed by: a processor, such as a processor at hospital data center 426, a processor of a workstation, such as workstations 432, 434, and 444 of fig. 4 and 5, a border device within or coupled to the hospital network, or any suitable combination thereof. Although the method 600 and other methods 650, 700, 750, and 800 herein are described primarily with respect to fig. 4 and 5, it should be understood that the method 600 and other methods may be implemented by other systems and components without departing from the scope of this disclosure.

The method 600 begins at 602. At 602, a bed primary data file may be generated and transmitted to a resource utilization server, such as resource utilization server 202. The bed main data file may include bed data for a facility and may include designated fields including system name, hospital Identification (ID), ward ID, ward display name, ward type, room ID, room display name, bed ID, bed display name, service (e.g., heart), care group level (e.g., adult ICU), ventilator available, negative pressure, private, and active. In one example, bed primary data for a specified field may be extracted from a bed inventory database of a facility. Bed primary data may be updated over a larger period or upon user request. For example, during public health, one or more wards may need to be converted to an intensive care ward to cope with patient load, and thus may need to be updated over a longer period of time (e.g., weeks, months) based on the ongoing public health and overall patient load for the facility.

Next, at 604, occupancy data, infectious disease data, and critical resources data (including ventilator data) may be obtained from one or more hospital databases.

At 606, the method 600 can extract the desired data based on the specified file fields. Extracting the desired data includes: at 608, extracting expected infectious disease data based on the specified infectious disease file field; at 610, extracting expected occupancy data based on the specified occupancy file field; at 612, extracting expected ventilator usage data based on the specified ventilator file fields; and at 614, extracting ventilator inventory data based on the specified ventilator inventory file field.

The expected infectious disease file fields may include a timestamp field, a system field, a facility field, a ward field, a bed field, and a flag field for an infectious disease state. The flag field may include an indication of the patient's infectious disease status (such as PUI or infectious disease positive). PUI data and infectious disease positive data can be obtained based on the infectious disease data obtained by method 1100. For example, the healthcare/hospital database processor may perform the method 1100 described with respect to fig. 11A to determine the number of PUIs and infectious disease positive patients at the facility and store the processed data in the database. Accordingly, desired infectious disease data can be extracted from the processed data. In this way, for facilities that are not part of the data sharing network, these facilities may not share patient personal information, but rather only the desired infectious disease data (which may be helpful for critical resource planning, monitoring public health and disease progression) may be extracted and sent to the resource utilization server for further data aggregation, processing and presentation of the user interface.

The expected occupancy data may include a timestamp of the record field, a system field, a facility field, a ward field, a room field, a bed field, an occupancy field, a freeze field, and a negative pressure field. The data values for each of the above fields may be extracted from one or more of a hospital database and an EMR.

The expected ventilator data fields may include system name, facility name, category (e.g., invasive or non-invasive), serial number, model, and operating state. In one example, the healthcare/hospital database processor may execute the method 1000 of fig. 10 to determine ventilator operating state data based on EMR data. Desired ventilator state data regarding the operating state may be extracted from the processed data. In another example, the desired ventilator data fields may also include a ventilator start time and a ventilator stop time, as well as one or more other input fields corresponding to data that may be needed by the resource utilization server to perform method 1000. Ventilator data available from EMR data without any additional personal patient information is used for resource utilization server processing.

The expected ventilator inventory data fields may include system name, facility name, category (e.g., invasive or non-invasive), serial number, model, which fields may be extracted from, for example, a hospital ventilator inventory database.

Fig. 9 shows an exemplary expected occupancy flat file field, an expected infectious disease flat file field, and an exemplary ventilator inventory flat file field at 920, 940, and 960, respectively. Upon extracting the data corresponding to the desired fields, at 616, an occupancy flat file, a ventilator usage flat file, a ventilator inventory flat file, and an infectious disease flat file may be generated. For example, the flat file may be provided in comma-separated value format.

Next, the generated flat file may be periodically transmitted to a resource utilization server to generate national capacity user interface data. In one example, the flat file may be transmitted via SFTP. The period of periodic transmission may be such that the data feed is transmitted in near real-time. In one example, the data feed may be transmitted every three minutes. In another example, the time period may be less than 3 minutes or greater than 3 minutes, but less than one hour (60 minutes), such that the interface data is continuously updated. For example, the time period may be once every 30 seconds. Further, it may be noted that one or more fields (in particular, a system field, a facility field, a ward field, a room field, and a bed field) in each of the occupancy plane file, the ventilator plane file, and the infectious disease plane file are associated with the system field, the facility field, the ward field, the room field, and the bed field in the bed master template. That is, for a given bed, the data in the generated flat file field should be the same as the data provided in the bed master template.

Fig. 6B is a flow diagram illustrating a high-level method 650 of generating one or more data feeds for a national capacity module, such as the national capacity module 208 of fig. 2-5, according to a second embodiment. In particular, method 650 describes generating an HL7 data feed and a flat file data feed. For example, in addition to flat file data feeds, a facility that is part of a data sharing network may transmit HL7 data feeds from an EMR. In this embodiment, method 650 is implemented to generate a filtered HL7 data feed in addition to a flat file data feed.

The method begins at 652. Steps 652 and 654 are similar to steps 604 and 604 at fig. 6A and will not be described again herein for the sake of brevity.

Next, at 660, the method 650 includes extracting desired data based on the specified file field 660. Extracting the desired data includes: at 662, desired infectious disease data is extracted based on the specified infectious disease file field; at 664, extracting desired occupancy data based on the specified occupancy file fields; and at 666, extracting ventilator inventory data based on the specified ventilator inventory file field. Steps 662, 664, and 666 are similar to steps 608, 610, and 614 at FIG. 6A.

Next, similar to step 616 of FIG. 6A, at 668, method 650 includes generating a flat file for each extracted data. Specifically, step 668 includes generating an occupancy flat file, a ventilator inventory flat file, and an infectious disease flat file.

Next, at 670, the generated flat file may be periodically transmitted to a hospital data center, for example, to a virtual machine system provisioned within the data center. The virtual machine system may then transmit the data to the resource utilization server.

Returning to step 654, after acquiring occupancy data, infectious disease data, and critical resources data, the method 650 may proceed in parallel to 656. At 656, the method 650 includes generating a filtered HL7 data feed, the filtered HL7 data feed including one or more of filtered ADT data, filtered ORU data, and filtered ORM data. The filtered HL7 data feed may or may not include fully identified patient data. The unfiltered HL7 data feed can be obtained from EMR data, which can be obtained from a hospital EMR database at a hospital data center and/or from an EMR workstation processing and storage system with non-transitory memory, and one or more filters can be applied to obtain filtered ADT, ORM, and ORU data.

In some embodiments, the filtered ADT data may include admission, discharge, and transfer data without personal patient information and demographic information. In one example, the filtered ADT data feed may be used by the national capacity module to calculate an admission rate, a discharge rate, and a transfer rate for the intensive care unit for a desired period of time. The filtered ORM data feed for the national volume module may include ORM lab order data related to infectious disease testing, and ORM key resource data, including ventilation application orders and suspension orders. Similar to the filtered ADT data, the filtered ORM data may not include patient personal information and patient demographic information. Further, the filtered ORU data feeds without patient personal and demographic information may include an ORU lab data feed and an ORU ventilator flow data feed. The ORU lab data feed may include test results observed from the infectious disease test order, as well as ventilator operation data, including ventilator start time, ventilator stop time, ventilator identifier, and ventilator type.

In other embodiments, a fully identified HL7 data feed can be generated. However, even for the fully identified HL7 data feed, one or more filters can be applied to extract specific key resource utilization data and infectious disease data. For example, a fully identified HL7 data feed may include filtered ventilation utilization data, so a ventilator start time, ventilator stop time, ventilator type, and ventilator identification may be extracted, and other ventilation information may not be included in order to increase the processing speed of the resource utilization server. For example, the filtered ADT data may include filtered admission data, discharge data, and transfer data with fully-identified patient information (such as personal patient information and demographic information). The filtered ORM data feed for the national volume module may include filtered ORM lab order data related to infectious disease testing, and filtered ORM critical resource data, including ventilation application orders and suspension orders. Similar to the filtered ADT data discussed in this embodiment, the filtered ORM data may include patient personal information and patient demographic information. Similarly, the filtered ORU data feed may include patient personal information and demographic information.

After generating the filtered ADT, ORU, and ORM data, the method 650 includes, at 658, transmitting the generated filtered data to a resource utilization server via the virtual machine system. Then method 650 ends.

In this way, by providing specific data to the resource utilization server, processing at the server to generate user interface data is greatly improved, thereby providing real-time or near real-time data updates via the GUI described herein.

Fig. 6A depicts generating a flat file data feed, and fig. 6B depicts generating a flat file data feed and a filtered HL7 data feed. In a third embodiment, a fully identified and unfiltered HL7 data feed including patient personal information and demographic information can be transmitted to a resource utilization server. In some examples, the national capacity module may utilize only flat file data feeds (e.g., occupancy flat files, ventilator inventory flat files, and infectious disease flat files).

While FIGS. 6A and 6B depict generating a data feed for a national capacity module for generating user interface data for a national capacity GUI, FIGS. 7A and 7B depict a first and second embodiment, respectively, of generating a data feed for a key resource module of a resource utilization server; and FIG. 8 depicts a first embodiment of generating a flat file data feed for an infectious disease module of a resource utilization server.

In particular, FIG. 7A depicts generating a flat file data feed. Steps 702, 704, 708 and 716 are similar to steps 602, 604, 610 and 618. Referring to steps 710 and 712, key resource utilization and key resource inventory data based on the corresponding specified flat file feed may be obtained. If the critical resource is a ventilator, steps 710 and 712 are similar to steps 612 and 614. It should be understood that other critical resource data may be similarly processed.

Further, with respect to step 708, the desired occupancy data may include additional indications with respect to the intensive care unit. For example, the desired bed occupancy data may include indications of an ICU, MCU, sub-atmospheric unit, and the like.

Upon extracting the desired flat file data, at 714, method 700 may generate a occupied flat file, one or more key resource flat files, and one or more key resource inventory flat files.

Turning now to FIG. 7B, a second embodiment of generating flat files and HL7 data feeds for key resource modules is shown. Steps 752, 754, 760, 768, and 770 are similar to steps 702, 704, 706, 714, and 716. Additionally, filtered HL7 data generation is performed at step 756. At 756, the method 750 includes generating filtered ADT, ORM, and ORU data. The generation of filtered HL7 data is similar to the filtered data feed for the national capacity module at step 656 at fig. 6B, except that ORM and ORU infectious disease laboratory tests and results are not included for the key resource module.

Furthermore, as discussed with respect to fig. 6B, the second embodiment of fig. 7B may not include fully identified patient data. Furthermore, the third embodiment of generating a data feed for a key resource may include fully identified filtered HL7 data in addition to the flat file data described in FIG. 7B.

Next, in fig. 8, an exemplary method 800 of generating flat file data for an infectious disease module according to the first embodiment is shown. Steps 802, 804, 810, 812, 814 and 816 are similar to steps 602, 604, 610, 612, 614 and 616 in fig. 6A. Referring to step 808, the desired infectious disease data may be extracted based on one or more additional infectious disease flat file fields. The one or more additional infectious disease flat file fields may include infectious disease data generated based on the infectious disease assessments discussed in fig. 11A-11C. For example, the facility/hospital data processor may acquire one or more previous and current EMR data corresponding to infectious disease tests and results, process them based on the method 1100 described at fig. 11, and output the infectious disease status of the patient. In one example, the additional data field may include information regarding whether the patient has tested positive at least once or never tested positive. The additional data fields may include data fields corresponding to patient data that may be used by the infectious disease module to determine patient load and patient activity that may be presented in the infectious disease interface as shown in fig. 29-32 and 34. The additional data fields may include an infectious disease bed maintenance data field (e.g., an applied EVS) under which an infectious disease bed maintenance status (e.g., true or false) may be provided.

The second embodiment of generating a flat file feed and a filtered HL7 data feed (without fully identified patient information) for the infectious resources module is similar to generating a flat file feed and an HL7 data feed for the national capacity module discussed in FIG. 6B.

Furthermore, in addition to the flat file data described in fig. 8, the third embodiment of generating a data feed of infectious disease resources may also include fully identified unfiltered HL7 data.

Turning next to fig. 10, a flow diagram is shown illustrating a method 1000 for tracking ventilator usage across one or more hospitals or medical facilities. The method 1000 may be performed according to instructions stored in a memory of a computing device in communication with the one or more hospitals or medical facilities, such as the resource utilization server 202. The method 1000 is described herein as being performed to detect a ventilation status of an individual ventilator in order to update a ventilator count for a desired geographic area. It should be appreciated that the method 1000 may be performed for each of a plurality of ventilators connected to/configured to transmit data to a resource utilization server.

At 1002, ventilation data and patient demographic data are received. The received ventilation data and patient demographic data may include ventilator start times, ventilator stop times, and ventilator type (e.g., invasive or non-invasive), as indicated at 1004. The received ventilator data and patient demographic data may include a current patient location of a patient connected to the ventilator, as indicated at 1006. The ventilation data and patient demographic data may be received from a hospital data center via a ventilator inventory/usage data feed, as described above with respect to fig. 5, or via other suitable data feeds as described herein.

At 1008, method 1000 includes determining whether the patient is within a desired area (such as a desired facility, a desired system, a desired state, or a desired region) based on the received current patient location. The desired area may be determined based on the intended purpose/use of the ventilator count. For example, if the ventilator count is for a particular hospital (e.g., to be displayed as part of a hospital-specific GUI), the desired area may be the hospital. If the ventilator count is for a particular geographic area, such as all hospitals in a particular state, the desired area may be the particular geographic area. The desired area may be selected by the user or automatically determined by the resource utilization server based on which ventilator count the server is currently determining/updating.

If the patient is not located within the desired area, for example if the patient is located at a first hospital and the desired area is a second hospital, the method 1000 may proceed to 1010 to not use the ventilator data and patient data for the desired area. The method 1000 may then return. It should be appreciated that rather than discarding the received ventilator data and patient data, the ventilator data and patient data may be used to update the ventilator count for the region in which the patient is located. If the patient is within the desired region, method 1000 proceeds to 1012 to determine if a ventilator start time has been indicated and a ventilator stop time has not been indicated or a ventilator start time has been indicated after the ventilator start time. When the ventilator start time is indicated, the operator has commanded the ventilator to start operation (whether now or in the future), which indicates that the ventilator is in use or is currently about to be used. If a stop time has not been indicated, this indicates that the ventilator is scheduled for long-term use, rather than rapid use for maintenance or other reasons. Thus, the combination of a start time and no stop time indicates that the ventilator is in use. The indicated ventilator start time after the ventilator stops indicates that the ventilator has been restarted after the stop, which also indicates that the ventilator is in use.

If a ventilator start time has not been indicated (regardless of any indication of ventilator stop time), or if a ventilator start time has been indicated but a ventilator stop time has also been indicated or a ventilator start time after a ventilator stop time has not been indicated, method 1000 proceeds to 1014 to confirm that a ventilator is not in use. At 1016, the ventilator usage status (e.g., not in use) and ventilator type are provided to each of the infectious disease module, the key resource module, and the national capacity module. The ventilator usage status may be used to adjust the ventilator usage count/ventilator occupancy. For example, the ventilator usage count may include a count of all ventilators in use in the desired area, and the ventilator occupancy may include a proportion of all ventilators in use in the desired area. If the ventilator evaluated via method 1000 was previously in use (and is therefore counted as occupied/in use in ventilator count/occupancy), the determination at 1014 that the ventilator is not in use may be applied to remove the ventilator from ventilator count/occupancy. The method 1000 may then return.

Returning to 1012, if it is determined that a ventilator start time is indicated and a) a ventilator stop is not indicated or b) a ventilator start time is indicated after the ventilator stop time, method 1000 proceeds to 1018 to determine whether to use a non-invasive ventilator on the patient. If the patient is using a non-invasive ventilator (e.g., the answer to the question of whether the patient is not using a non-invasive ventilator is no), then method 1000 proceeds to 1022 to confirm that a non-invasive ventilator is in use, and then method 1000 proceeds to 1024 (explained below). If the non-invasive ventilator is not being used with the patient (e.g., the answer to the question of whether the patient is not using the non-invasive ventilator is yes), then the method 1000 proceeds to 1020 to confirm that the invasive ventilator is in use. At 1024, a duration that has elapsed since the indicated ventilator start time is determined. At 1028, a ventilator usage status (e.g., in use), a ventilator type (e.g., invasive or non-invasive), and a duration since start time are provided to each of the infectious disease module, the key resources module, and the national capacity module. The ventilator usage status may be used to adjust the ventilator usage count/ventilator occupancy, as described above. For example, if a ventilator evaluated via the method 1000 was not previously used (and thus is counted as unoccupied/unused in ventilator count/occupancy), the determination at 1020 or 1022 that the ventilator is in use may be applied to add the ventilator to the ventilator count/occupancy. The method 1000 may then return.

Fig. 11A is a flow chart illustrating a method 1100 for determining a disease state of a patient. The method 1100 may be performed according to instructions stored in a memory of a computing device in communication with the one or more hospitals or medical facilities, such as the resource utilization server 202. Method 1100 is described herein as being performed to determine patient status for COVID-19, but it should be understood that method 1100 may be performed to determine patient status for other diseases, particularly emerging infectious diseases.

At 1102, disease test data for a patient is obtained. The test data may include test results (e.g., positive, negative, or indeterminate) for a disease (e.g., COVID-19). The test data may include data/results of currently/recently performed tests. When available, the test data may include data/results of one or more previous tests (e.g., previous test data and/or n-2 test data). The test data may be received from the hospital data center via an infectious disease feed (as explained above with respect to fig. 5), through an HL7 data feed and/or through a flat field data feed (as explained above with respect to fig. 4). Each time test data for a patient is sent via a data feed described herein, the test data may be stored in memory on the server and obtained when instructed to determine the patient's disease state.

At 1104, the method 1100 includes determining whether the patient has tested positive for the disease at least once based on the obtained test data. If the patient has not tested positive at least once (e.g., all available test data for the patient includes only negative and/or indeterminate results), the method 1100 proceeds to 1106 to determine the COVID state based on the n-2 previous test data, the previous test data, and/or the current test data according to a set of rules/logic for the patient who has not tested positive. This set of rules/logic is shown in FIG. 11C and explained in more detail below. In short, due to viral latency, potential testing problems, and other issues, the lack of a positive test result does not necessarily indicate a negative for a patient with a codv, particularly because the system described herein may be receiving test results from patients who are hospitalized and/or otherwise suspected of having a codv. Although the set of rules/logic for patients for whom a codv has not been tested positive includes all possible test scenarios, the rules/logic may be simply summarized as: if the patient has a negative test result for the current test without a previous positive test result, indicating that the patient is negative for the COVID in response to a first threshold amount of time having elapsed since the current test was performed, otherwise indicating that the patient is under investigation; and if the patient has an uncertain test result for the current test without a previous positive test result, indicating that the patient is under investigation until a negative test result is received or until a first threshold amount of time has elapsed since the current test was performed while the patient is asymptomatic, then indicating that the patient is negative. Method 1100 then proceeds to 1110, which will be described in greater detail below.

If it is determined at 1104 that the patient has tested positive for COVID at least once, the method 1100 proceeds to 1108 to determine the patient COVID status based on the n-2 previous test data, and/or current test data according to a set of rules/logic for the patient who has tested positive. This set of rules/logic is shown in FIG. 11B and explained in more detail below. In short, due to viral latency, potential testing problems, differences between symptom presentation and viral clearance times, and other problems, the time at which a patient that is positive for a codv is no longer positive may be difficult to discern via standard mechanisms (e.g., symptoms, time since symptom presentation, etc.). While the set of rules/logic for patients who test positive for codv includes all possible test scenarios, these rules/logic may be simply summarized as: if the patient has at least one previous positive test result, indicating that the patient is positive for the disease until: a) a second threshold amount of time has elapsed since a first negative test result following a previous positive test result; or b) receiving two negative test results after a previous positive test result, the two negative tests conducted within at least a third threshold amount of time between the two tests. The thresholds described herein may be based on CDC guidelines and/or may be set by the user and may be updated as the criteria changes due to a constant understanding of the coronavirus and COVID.

At 1110, once the patient disease state for the codid is determined, the patient disease burden and patient disease activity at both system and facility levels may be determined. The patient disease burden may include the total number of positive patients, the number of currently investigated patients, and the number of negative patients at the facility (or system wide). The patient disease activity may include the number of patients tested positive per day, the change in positive patients over a specified duration of time, the number of patients who have recovered (e.g., previously tested positive and now considered negative), the expected number of positive patients, and/or the expected number of tests to be performed in the future, etc. In some examples, the number of positive patients may be cumulative such that recovered patients are still included. In other examples, the number of positive patients may include only those patients deemed to have an active COVID positive status. Likewise, the number of negative patients may include only patients that are negative and never tested positive. In other examples, the number of negative patients may include patients who were previously positive but are now considered negative.

At 1112, the COVID status (including patient load and patient activity) is provided to the infectious disease module and national capacity module, which can populate a dashboard that will be visualized as one or more of the GUIs described herein, using the status, patient load, and/or patient activity. Method 1100 then returns.

Fig. 11B shows an exemplary table 1120 that illustrates a set of rules/logic that may be applied to determine the codv status of patients who have tested positive for codv at least once. The table 1120 includes a first column 1122 that may depict n-2 test results, a second column 1124 that may depict previous test results, a third column 1126 that may depict current test results, and a fourth column 1128 that shows the disease state specified for the test results shown in the respective row. For the first set of columns 1122, the first column is the result of tests performed greater than a second threshold amount of time (herein, Y, such that the column is named > Y ago), and the second column is the result of tests performed less than the second threshold amount of time (< Y ago). For the second set of columns 1124, the first column is the result of a test performed greater than a second threshold amount of time (> Y ago), the second column is the result of a test performed less than the second threshold amount of time (< Y ago), and the third column is used to determine whether a third threshold amount of time (Z) has elapsed between the time the previous test was performed and the time the current test was performed. For the third set of columns 1126, the first column is the result of tests performed greater than the second threshold amount of time (> Y ago), and the second column is the result of tests performed less than the second threshold amount of time (< Y ago).

The thresholds (Y and Z) may be user configurable and/or may be based on current CDC guidelines. As shown in fig. 11B, the second threshold (Y) may be 5 days, and the third threshold (Z) may be 24 hours. The second threshold may also include that the patient is asymptomatic during the indicated amount of time.

The table 1120 may be stored in the memory of the resource utilization server 202 and may be applied to determine the current codid state of a patient who has performed at least one positive test. As shown in table 1120, if a patient tests positive for COVID in the current test, the patient is considered positive regardless of the past test results. However, if the patient tests negative in the current test or if the current test result is uncertain, the previous test result and/or the n-2 test result may be analyzed to determine the current patient status. Names in the fourth column 1128 may include positive (CV19+), under-investigation (PUI-NEG), and negative (deleted from the block). Names deleted from the tiles may indicate that the patient is no longer tracked on the hospital or larger system level COVID patient tracker, but the patient may still be counted in the cumulative disease positive count.

For example, if a previous test was performed less than five days ago and two negative tests were performed less than 24 hours apart, a patient who tested positive in the n-2 previous test, negative in the previous test, and negative in the current test would be considered under investigation. However, if the previous test was performed five days ago, the patient will be considered negative regardless of the time between negative tests. In short, a patient will be considered negative and will require a negative test and then no positive will be tested again after 5 days of asymptomatic use, or negative and will require two consecutive negative tests, wherein the two tests are separated by at least 24 hours.

Fig. 11C illustrates an exemplary table 1140 that represents a set of rules/logic that may be applied to determine the codv status of patients who have not tested positive for codv at least once. Table 11240 includes a first set of columns 1142 that may depict n-2 test results, a second set of columns 1144 that may depict previous test results, a third set of columns 1146 that may depict current test results, and a fourth column 1148 that shows the disease state specified for the test results shown in the corresponding row. For the first set of columns 1142, the first column is the result of tests performed greater than a first threshold amount of time (herein, X, such that a column is named > X ago), and the second column is the result of tests performed less than the first threshold amount of time (< X ago). For the second set of columns 1144, the first column is the result of tests performed greater than a first threshold amount of time (> X ago), and the second column is the result of tests performed less than the first threshold amount of time (< X ago). For the third set of columns 1146, the first column is the result of tests performed greater than the first threshold amount of time (> X ago), and the second column is the result of tests performed less than the first threshold amount of time (< X ago).

The threshold (X) may be user configurable and/or may be based on current CDC guidelines. As shown in fig. 11C, the first threshold (X) may be 14 days, which may be based on the longest possible (known) latent period of the coronavirus.

The table 1140 may be stored in the memory of the resource utilization server 202 and may be applied to determine the current codv state for patients who have not performed a positive test. As shown in table 1140, negative test results are not an automatic indicator that the patient is COVID negative because the coronavirus may be at low viral load and cannot be detected by the test. Thus, a patient is considered negative only if the patient has performed a negative or indeterminate test at least a first threshold amount of time before. Otherwise, the patient is considered under investigation (although presumably negative, as indicated by the PUI-NEG status).

Next, fig. 12 shows a flow diagram illustrating a high-level method 1200 for generating user interface data for a national capacity Graphical User Interface (GUI) showing hospital occupancy and key resource capacity at various geographic levels in a hospital network, including at the national, regional, state, and hospital system (within state) levels. The country capacity GUI is described with respect to fig. 22-28 and 37-44. The method 1200 may be performed according to instructions stored in a memory of a computing device in communication with one or more hospitals or medical facilities, such as the national capacity module 208 of the resource utilization server 202, a border device connected to the resource utilization server, or any suitable combination thereof.

At 1202, method 1200 includes receiving a plurality of data feeds from each of a plurality of facilities across various geo-hierarchical regions (e.g., countries, regions, and states). The facility is a healthcare facility, such as a hospital, that can provide in-patient care and that has or can be modified to include critical care capacity. Exemplary facilities are shown and described in fig. 1-5. In this disclosure, the terms facility and hospital are used interchangeably. The plurality of data feeds may include one or more of an HL7 data feed and a flat file data feed, as discussed with respect to fig. 2-5 and 6A, 6B, 7A, 7B, and 8. The plurality of data feeds may include one or more of occupancy data, infectious disease data, critical resource data, and EMR data. Fig. 6A, 6B, 7A, 7B, and 8 depict details of generating the plurality of data feeds.

At 1204, method 1200 includes determining each geo-stratification region, total number of beds, total occupancy, total number and occupancy of beds per intensive care unit within each geographical region, total ventilator, ventilator usage, PUI, and disease positive data. In particular, the received data feed may be processed to generate user interface data for populating and updating the national capacity user interface in real-time or near real-time.

Next, at 1206, method 1200 includes determining alert states for bed occupancy and critical resource usage (e.g., ventilator usage) for each geo-stratification region based on one or more thresholds. An exemplary alert structure based on various thresholds for occupancy and ventilator usage is shown below in table 1.

TABLE 1。

Table 1 above shows a first set of thresholds and threshold ranges that provide red, amber, no alert, or green alerts relative to ICU occupancy under scenario 1; a second set of thresholds and threshold ranges providing a red, amber, no alert, or green alert relative to total occupancy in case 2; and a third set of thresholds and threshold ranges that provide a red, amber, no alert, or green alert with respect to ventilatory use. It should be understood that the threshold may be configured by the administrative user and applies to all users. Further, the threshold range may vary based on the type of patient room and the type of public health condition.

Next, at 1208, the method 1200 includes aggregating user interface data for updating and populating the national capacity graphical user interface. The national capacity graphical user interface may be an aggregated tile showing total bed occupancy for various geo-tiered zones that can be selected by the user, intensive care unit (e.g., ICU, IMC, ACUTE, OBS) occupancy for adult and pediatric patients, critical resource usage (e.g., total ventilator usage), and infectious disease states. The aggregated national capacity tile (i.e., the national capacity GUI) may be displayed at a display unit of the client device, such as a workstation of a hospital command center. Additionally, one or more alert states may be displayed when selected. The alert status may enable the user to see at a glance the hospital under maximum stress (red) and the hospital with the maximum available capacity to help (green). While the alert view may be adjusted by various users at the workstation based on the desired display configuration, the thresholds used to indicate various alerts described above may be changed only by authorized users.

After generating the user interface data, the method 1200 includes outputting the generated UI data via the national capacity GUI. In one example, the computing device may transmit user interface data, which may then be used by a template stored at the workstation interface to populate various tiles, sub-graph blocks, and fields within the aggregated tile of the national capacity GUI. In another example, the populated updated real-time data (or near real-time data) can be utilized at the resource utilization server to generate an aggregated tile and transmit the aggregated tile to the requesting workstation for display. In some examples, a suitable combination of the above methods for populating and displaying the GUI may be used.

Turning next to fig. 13, a flow diagram is shown illustrating a high level method 1300 for generating user interface data for a key resource Graphical User Interface (GUI) showing key resource utilization at various geographic levels in a hospital network, including country, region, state, and hospital system (within state) levels. The key resource GUI is described with respect to fig. 15-21. The method 1300 may be performed according to instructions stored in a memory of a computing device in communication with one or more hospitals or medical facilities, such as the critical resources module 206 of the resource utilization server 202, an edge device connected to the resource utilization server, or any suitable combination thereof.

At 1302, method 1300 includes receiving a plurality of data feeds, including occupancy data, key resource data, and EMR data, from each of a plurality of facilities across various geo-hierarchical regions (e.g., countries, regions, and states). Step 1302 is similar to step 1202.

Next, at 1304, method 1300 includes determining critical resource usage data for an intensive care unit (including an ICU, PCU, MT/MS unit, OBS unit, negative pressure unit) and a ventilator for each geo-stratification zone.

Next, at 1306, method 1300 includes determining alert states for critical care unit occupancy and critical resource usage (e.g., ventilator usage) for each geo-stratification region based on one or more thresholds. Exemplary thresholds for total bed occupancy, ICU occupancy, and ventilator usage are shown and discussed with respect to table 1.

Next, at 1308, method 1300 includes generating user interface data for generating a GUI for the key resource based on the geographic area requested by the user including the alert indication. For example, generating user interface data includes aggregating user interface data for updating and populating a key resource graphical user interface. The critical resource graphical user interface may be a critical resource aggregation tile showing critical care unit (e.g., ICU, PCU, MT/MS, OBS, negative pressure unit) occupancy, critical resource usage (e.g., total ventilator usage), and infectious disease status for various geo-partitioned areas that can be selected by the user. Exemplary key resource GUIs are illustrated with respect to fig. 15-21. After generating the user interface data, method 1300 includes outputting the generated UI data via the key resource GUI. Outputting the generated UI data may be performed as discussed above with respect to fig. 12.

Next, fig. 14 shows a flow diagram illustrating a high level method 1400 for generating user interface data for an infectious disease Graphical User Interface (GUI) showing occupancy of resources and infectious disease data within a single hospital or hospital system. The infectious disease GUI is described with respect to fig. 29-34. The method 1400 may be performed according to instructions stored in a memory of a computing device in communication with one or more hospitals or medical facilities, such as the infectious disease module 204 of the resource utilization server 202, a border device connected to the resource utilization server, or any suitable combination thereof. In some embodiments, method 1400 may be performed by a computing device (such as a hospital data center processing unit) in a hospital data network. For example, one or more processing units in a hospital data center may be configured to include a set of virtual machines that may receive a plurality of data feeds from the hospital data center and/or a workstation, process the received data feeds, generate user interface data for an infectious disease graphical user interface, and output the data via the user interface.

At 1402, the method 1400 includes receiving a plurality of data feeds, including one or more of occupancy data, critical resource data, and EMR data, from each of a plurality of facilities across a hospital system including one or more facilities. Step 1402 is similar to steps 1202 and 1302 discussed above.

Next, at 1404, method 1400 includes determining, for a given ward and/or hospital system, patient load, intensive care dedicated bed usage status and availability, patient counts for tests and results of infectious diseases, status of environmental services of the intensive care dedicated bed, ventilator orders, use and suspension order status.

Next, at 1406, method 1400 includes determining alert states for various intensive care unit occupancies and critical resource usage (e.g., ventilator usage) for each unit within the facility and/or hospital system based on one or more thresholds. Exemplary thresholds for total bed occupancy, ICU occupancy, and ventilator usage are shown and discussed with respect to table 1.

Next, at 1408, the method 1400 includes generating user interface data for generating the infectious disease GUI based on the facility and/or hospital system requested by the user. For example, generating user interface data includes aggregating user interface data for updating and populating the infectious disease graphical user interface. The infectious disease graphical user interface may be an infectious disease aggregation tile that illustrates critical care unit (e.g., ICU, PCU, MT/MS, OBS, negative pressure unit) occupancy, critical resource usage (e.g., total ventilator usage), and infectious disease status for a facility and/or hospital system that can be selected by a user. An exemplary infectious disease GUI is shown and described below with respect to fig. 29-34.

Continuing, fig. 15-44 illustrate various GUIs that may be displayed on a display of a display device, such as client device 130, for interacting with a resource utilization system, such as resource utilization server system 102, resource utilization server 202, of fig. 1, and the like. GUI 1500, 2200, and/or 2900 may be displayed in response to a user request to display a GUI. For example, a user may launch one or more GUIs by selecting the appropriate application icon displayed on the display. When GUI 1500, 2200, and/or 2900 is launched, the user may be authenticated via a suitable authentication method, such as via a password, facial recognition, fingerprint recognition, and so forth.

The GUI 1500, 2200, and/or 2900 may be used to display how critical resources, such as beds, ventilators, etc., are distributed throughout the hospital network, including displaying indications of which hospitals critical resources may be in short supply and which hospitals may have available resources. Thus, an operator, such as a healthcare administrator or health management authority, may use GUIs 1500, 2200, and/or 2900 to view critical resources within a hospital network in order to allocate resources in an optimal manner to obtain the best possible patient outcome across a healthcare delivery system. The GUIs 1500, 2200, and/or 2900 may be used to display one or more dashboards having hospital-specific information, such as the dashboard 104 of the collaborative resource utilization system 100, or one or more dashboards that may be used to display data with aggregated data about a hospital within a given city, county, state, region, country, etc.

FIG. 15 illustrates an exemplary GUI 1500 that displays hospital key resource data at various geographic scopes and subdivided by resource type. The GUI 1500 may include control elements such as a drop-down menu 1504 to filter data displayed in the GUI 1500 by resource or by group of resources (e.g., bed, ventilator, key resource, etc.), as shown in fig. 16. Additionally, the GUI 1500 may include display elements such as an information icon 1512 and a settings icon 1514 that, when selected, may trigger the display of a display panel with additional information or selectable options for further filtering of the displayed content. In some implementations, selecting the information icon 1512 or the settings icon 1514 can trigger sliding in from one side and partially obscuring the display panel of the GUI 1500. Selecting the information icon 1512 or the settings icon 1514 may also trigger a display panel that pops out as a separate window or any other type of display panel.

GUI 1500 may be configured to initially display certain types of hospital resources within a certain range. For example, GUI 1500 may show key hospital resources at the national level in the hospital network, as indicated by scope indicator 1502. As shown in GUI 1500, the initial country view may display aggregated data from different regions of the country (such as north CFD, south CFD, zhongguan, southeast, etc.). The different regions whose data has been aggregated may be displayed on top of GUI 1500 as a series of tabs, such as region tab 1508, each of which may be selected to view the resource data for the corresponding region. Tabs may be selectable indications may be displayed on each tab, such as down arrow 1510, where selection of a tab may trigger display of data at the range level indicated by the tab. For example, selecting tab 1508 (e.g., north CFD) may display a new dashboard showing data specific to the regional north CFD, as shown in fig. 4.

A dashboard reference tile 1506 may also be included, which indicates the scope of information currently displayed within the GUI 1500. For example, the dashboard reference tile 1506 may indicate that the data displayed within the GUI 1500 belongs to an entire hospital system (e.g., Adventhealth), or may indicate that the data displayed within the GUI 1500 belongs to a hospital of a hospital system located in a particular region (such as north CFD). The dashboard reference tile 1506 may be a different color, or may employ bold text or similar distinguishing features to highlight it. GUI 1500 may also include control elements such as right and left arrows 1542 that allow the user to scroll horizontally through other regions that may not be displayed in GUI 1500 due to display width limitations.

The GUI 1500 may display the hospital resource information as a series of tiles arranged in columns and rows within a tiled arrangement, where a row may indicate the type of resource or group of resources to be displayed (based on the selections provided by the drop-down menu 1504) and a column may indicate a category of data, such as country, region, and so forth. Further, each column may be divided into subcolumns that display different types of data (e.g., resource occupancy, capacity, number of wards in use or available, etc.). The GUI 1500 may display a column header, such as column header 1516, column header 1518, and column header 1520, to indicate the type of data displayed in the tiles within the column. In the illustrated example, column header 1516 shows two category headers: a category header ("uncc") for the number of unoccupied (e.g., available) resource units, and a category header ("OCC") for the corresponding occupancy. For example, block 1526 indicates that there are 93 unoccupied beds in the adult observation ward throughout the hospital network, i.e., an occupancy of 58%. Column header 1518 shows three subheaders: a sub-header for the number of unoccupied resources ("uncc"), a sub-header for the capacity of the resource under consideration ("CAP"), and a sub-header for the number of resources located in the negative pressure ward ("NP"), NP in this case being shown as the ratio of occupied bed to total bed. Column header 1520 shows two category headers: a category header for total resource count ("CENSUS"), and a category header for occupancy ("OCC").

In one embodiment, occupancy may be expressed as a percentage (as shown by occupancy 1534), or via an icon such as occupancy icon 1536, 1538, or 1540. In the illustrated example, the occupancy icons 1536, 1538, 1540 graphically represent percentages via a thick line superimposed on a circle, where the perimeter of the circle represents 100%, and the thick line indicates a portion of the total perimeter. Additionally, color may be used to indicate availability or degree of use. For example, the occupancy icon 1536 is green, indicating that ventilator utilization is below a first threshold (e.g., low occupancy); the occupancy icon 1538 is amber, indicating that ventilator utilization is above the first threshold but below a second threshold (e.g., medium occupancy); and the occupancy icon 1540 is red, indicating that ventilator utilization is above a second threshold (e.g., high occupancy). In the example shown herein, the first threshold may be 89% and the second threshold may be 94%, such that when the corresponding occupancy changes to a value in the range of 90% -94%, the occupancy icon may change from green to amber, for example, and when the corresponding occupancy changes to a value in the range of 95% -100%, the occupancy icon may change to red.

For example, in fig. 15, the user has selected the grouping "adult" in the drop-down menu 1504, which indicates that the user wishes to view and compare the allocation of certain resource groups across adult care facilities/wards, subdivided in columns representing different regions. In one embodiment, the resources and resource groups selected by the user are displayed as row headers in the first column. The row header 1522 (e.g., "all") indicates that the first row displays the number of available resource units (e.g., beds) across all resource sub-groups. Row header 1524 (e.g., "adult ICU") corresponds to the subgroup "ICU," indicating that the second row contains data regarding adult ICU bed occupancy. GUI 1500 may display the multiple subgroups as additional rows, each row representing a resource, such as a bed, a ventilator, etc., in a given area (e.g., a disease Progression Care Unit (PCU), an observation ward (OBS), a negative pressure ward, etc.). It should be understood that the resources or wards described herein are for illustrative purposes and should not be construed as limiting.

Moving on top of the GUI 1500, a first data column (e.g., a second column) displays the amount and occupancy of unoccupied resources for the entire hospital system (Adventhealth), while second, third, fourth, and fifth data columns show the summarized data for the areas north, south, middle, and south-east CFD, respectively. The summary data displayed in each tile may include the number of unoccupied resources, capacity, number of patients, total number of individuals being treated, and occupancy. For example, block 1526 illustrates the number of unoccupied resources (e.g., beds) in an adult OBS ward in an entire national Adventhealth hospital network (in this case, 93), and the corresponding occupancy expressed as a percentage (in this case, 58%). Alternatively, the tile 1530 immediately to the right in the column indicates: there were 39 unoccupied beds in the CFD in the north of the region with a total capacity of 91 beds; there were 7 unoccupied beds in the negative pressure room, for a total of 15 beds; a total of 52 beds are in use (total capacity 91 minus unoccupied bed 39); the total occupancy is 57%, which is below a first threshold (e.g., 70%), indicating high availability. It should be appreciated that for some resources, some column headers may not be applicable. For example, block 1532 indicates that there are 95 unused ventilators in the CFD in north of the region, for a total of 566 ventilators. However, the ventilator is a mobile resource that can be moved to different locations, and thus no ratio is displayed for the negative pressure room.

Continuing, fig. 16-21 illustrate how control elements within GUI 1500 may be used to filter or narrow the scope of the illustrated data, for example by illustrating data for a single resource (such as a bed, ventilator, etc.) or a single region within a country, a single hospital within a region, a single ward within a hospital, etc. FIG. 16 shows an exemplary view 1600 of GUI 1500 in which a user has selected a drop-down menu 1504 to change the selection of data being displayed from its current grouping of "adult" (e.g., resources used in an adult patient room) to a different set of resources. For example, the user may select a drop-down menu item 1602 indicating "all" in order to display all resource types (not just adult rooms). As shown in the exemplary view 1600, the drop-down menu 1504 may include other hospital resources or groups of resources, such as key resources, children's resources (dates), resources from a given specialty, and the like. For example, if the user selects "key resources" in the drop-down menu 1504, the left column of the GUI 1500 will be populated with a list of hospital resources identified as being key. Resources identified as critical may be pre-established based on specific resource allocation requirements, for example, in the case of Covid19, a ventilator may be considered a critical resource. Similarly, resources not deemed critical will not be displayed. In some examples, resources may be considered critical based on average occupancy, rate of increase of occupancy, etc. (which may indicate that a particular resource is in demand and thus may be considered critical).

FIG. 17 shows a region view 1700 of GUI 1500 in which the user has limited the resources displayed in GUI 1500 to the region North CFD by selecting the region tab 1508 "North CFD" shown in FIG. 15. In the region view 1700, the current range of the GUI 1500 is updated in the range indicator 1502, indicating that data at the region level is being displayed instead of the country level. Similarly, dashboard reference block 1506 now indicates that data from a hospital located in the hospital network that is located in regional north CFD is being shown, and the regional tab north CFD has been replaced with a hospital tab 1702 (e.g., Deland hospital). The tabs for the south CFD, the central gate, and the rest of the southeast have been replaced with tabs indicating hospitals located in the north CFD of the selected region. As illustrated in fig. 15, right and left arrows 1542 may be used to scroll horizontally to the right or left in order to navigate between different hospitals located in the target area north CFD. The GUI 1500 may include control elements, such as a back arrow 1704, that allow the user to navigate back to the country level and expand the scope of the data being displayed.

As shown above in fig. 15, a control element such as a down arrow 1510 may be displayed on a hospital tab at the top of the GUI 1500 indicating that the scope of the displayed data may be further limited to the hospital level. Similarly, some of the data tiles may include down arrows 1706 to indicate that additional data may be viewed by hovering over or selecting the tiles (in this way, the GUI 1500 may trigger additional display panels). In one embodiment, the additional display panel may include a pop-up window as shown in FIG. 18.

FIG. 18 shows an exemplary region view 1800 of the GUI 1500, where a user hovers over a data point 1802, triggering a pop-up display panel 1804 with additional information relating to the data point 1802. The pop-up display panel 1804 may include a header that explains what the data points represent, e.g., data point 1802 represents the number of ventilators in use (at the Waterman hospital) and the value of the associated data point (e.g., 82). As shown in the illustrated example, the pop-up display panel 1804 may contain information such as a list of all patients or beds that have ventilators, a sequence number for each ventilator, an amount of time a ventilator has been used, and the like.

FIG. 19 shows a facility view 1900 of GUI 1500, in which facility-level resource utilization is displayed as indicated by scope indicator 1502. For example, the user may have selected a tab for the Lakeside hospital in the area view 1700 of fig. 17. The drop down menu 1504 indicates that the facility Lakeside has been selected, and as described above, the back arrow 1708 may allow the user to navigate back to the area level to expand the range of data being displayed. As shown in fig. 15, the facility view 1900 includes rows of resources or groups of resources, such as beds in different patient rooms (e.g., an intensive care unit, an observation unit, a pediatric unit, an adult unit, etc.), with information about each resource displayed in columns, such as a statistics column 1902, an occupancy column 1904, an unoccupied resources column 1906, a negative pressure resources column 1908, a discharge order column 1910, a transfer order column 1912, and a frozen resources column 1914. For example, block 1918 may indicate that there are 21 beds in use and 2 unoccupied beds in the negative pressure room.

Each row may contain a down arrow 1916 that may be selected to further narrow the scope of the information to only show resource utilization information for a given resource group. For example, the down arrow 1916 may be selected to view resource availability within an adult medical trauma/medical surgery (MT/MS) ward, as shown in fig. 21.

Continuing to FIG. 20, the exemplary facility view 2000 of GUI 1500 shows a series of pop-up display panels that may be triggered when a user hovers over or otherwise selects a data point in GUI 1500. For example, for the facility Lakeside (indicated by the dashboard reference block 1506), hovering over the data point 2002 may trigger a pop-up display panel 2004 that displays a list of frozen beds in the adult intensive care unit and the reason for being frozen.

Fig. 21 shows a ward view 2100 of GUI 1500 showing utilization of a given resource or resource type at the ward level of a hospital/medical facility (as indicated by scope indicator 1502). For example, the ward view 2100 may be displayed when the user selects the down arrow 1916 in the facility view 1900 corresponding to a row of adult medical trauma/medical procedure ward resources.

In the ward view 2100, the header line 2102 displays aggregated data regarding resource utilization for all adult medical trauma/medical procedure wards, while the row below the header line displays resource utilization data for individual wards. For example, row 2104 shows the total patient count and patient count for the Intensive Care Unit (ICU) and disease Progression Care Unit (PCU), occupancy, number of unoccupied beds, number of beds in the negative pressure chamber (both in use and unoccupied), number of hospital orders, number of transfer orders, and number of frozen beds, all for north 5 ward.

Fig. 22-28 show exemplary views of a GUI 2200 (e.g., a first embodiment of a national capacity GUI) for viewing resource utilization data in a hospital, region, state, etc. Like GUI 1500, GUI 2200 may be used to display how critical resources such as beds, ventilators, etc. are distributed throughout the hospital network, including displaying indications of which hospitals critical resources may be in short supply and which hospitals may have available resources.

The GUI 2200 may show hospital capacity across a national, regional, or state level hospital network, as indicated by the scope indicator 2202. As shown in GUI 2200, the default or initial country view can display aggregated data from different regions of the country (such as northeast, midwest, south, west, etc.), where the different regions are represented by rows. GUI 2200 can also include a slider button 2204 that can be used to toggle between state-based data and data from the Metro Statistics Area (MSA). Additionally, for any region, state, partition, facility, etc. displayed in, for example, GUI 2200, control elements such as statistics button 2222, unoccupied resources button 2224, and/or capacity button 2226, respectively, may be used to toggle the display of data between a total bed count, an available bed count, or a bed capacity.

The different types of resources available may be displayed at the top of the GUI 2200 as a series of resource tabs, such as a bed tab 2208, an adult patient room tab 2210, a pediatric patient room tab 2212, and/or a ventilator tab 2214, each of which may be selected in order to view the corresponding type of resource data. GUI 2200 may additionally include a resource column associated with a particular disease or condition, such as codid tab 2216. In addition, GUI 2200 can include display elements such as information icon 2218 and settings icon 2220 that, when selected, can display a panel with additional information or selectable options for further filtering of the display content. In some implementations, selecting the information icon 2218 or the settings icon 2220 may trigger sliding in from one side and partially obstructing the display panel of the GUI 2200, as explained in more detail below. Selecting the information icon 2218 or the settings icon 2220 may also touch a display panel or any other type of display panel that pops up as a separate window. The GUI 2200 may also include a search field 2207 in which the user may enter the name of a particular region, hospital, address, etc. in order to filter the data being displayed.

A dashboard reference tile 2206 may also be included that indicates the scope of information currently displayed within the GUI 2200. For example, the dashboard reference tile 2206 may indicate that the data displayed within the GUI 2200 belongs to a given country (e.g., the united states). The dashboard reference tile 2206 may be a different color, or may employ bold text or similar distinguishing features to highlight it.

The GUI 2200 may display the hospital resource information as a series of tiles arranged in rows and columns arranged in a vertical hierarchical structure within a flat layout, where the rows may indicate geographic areas of different sizes to be displayed, such as regions, states, divisions, and the like. For each resource tab 2208, 2210, 2212, 2214, and 2216 on top of the GUI 2200, one or more columns may indicate different categories of resources available under each tab (e.g., the resource "bed" may be divided into categories such as beds located in Intensive Care Units (ICUs), transition care units (IMCs), emergency care units, observation units, etc.). For example, in GUI 2200, row 2228 displays: in data column one ("all beds") is the total number of occupied beds and occupancy rates across the hospital network, followed by the total number of occupied beds and occupancy rates for adult ICUs, adult IMCs, adult emergency care units, etc. in other hospital wards that are displayed. Under the column "ventilators," block 2236 indicates the total number of ventilators being used (57,974) and the associated usage (81%) throughout the hospital network. Under the codid tab 2216, panel 2238 shows the total number of patients investigated (PUI, 1,114,944) and the total number of patients who tested positive for codd-19 (124,217).

Row 2228 includes a header tile 2240 that, in the illustrated example, indicates the highest level (e.g., network range total) in the data hierarchy displayed in GUI 2200. Header tile 2240 may include a down arrow 2230 indicating that row 2228 is expanded to include rows that represent data at a lower level of granularity. For example, row 2232 shows the number of occupied beds in the northeast region as a subset of the total indicated in row 2228. Further, rows for various partitions may be displayed below row 2232, such as partition tile 2234, which shows the number of occupied beds in the new england partition in the northeast region. In one embodiment, the down arrow 2230 may initially appear as a forward arrow indicating that row 2228 may be expanded (as shown in partition tile 2234 for new england), at which point it may become a down arrow to indicate nesting information that may be collapsed by selecting the down arrow. Accordingly, the GUI 2200 allows the user to selectively view various ranges of resource availability data, such as the number of occupied or unoccupied beds, ventilators, etc., by selectively expanding and/or collapsing rows on the dashboard.

Continuing, fig. 23, 24, and 25 show expanded views of the GUI 2200 in which data displayed in the GUI 2200 about available resources within the hospital network is successively presented as rows expanded in the hierarchical display. FIG. 23 shows an expanded view 2300 of GUI 2200 in which row 2304 (corresponding to middle Atlantic zone 2) has been expanded by selecting arrow 2302 (which transitions from a right arrow to a down arrow) to reveal state rows 2306, 2308 and 2310 in New Jersey, New York, and Pennsylvania, respectively. In an embodiment, a row below row 2304 (e.g., midwest, south, etc.) may shift downward to appear below row 2310 (pennsylvania) as row 2304 expands. Additionally, an alert indicator, such as alert indicator 2312, can be displayed in a row, which can provide a graphical indication of the availability of resources within the hospital represented by the row.

In embodiments, different colors or shapes of alert indicators may be used to indicate whether the occupancy or usage of a given resource (e.g., bed, ventilator, etc.) is below a first threshold, above the first threshold but below a second threshold, or above the second threshold. For example, an amber alert indicator 2312 shaped as a warning sign with an exclamation point may indicate an occupancy above the first threshold of 80% but below the second threshold of 90%. Similarly, the red alert indicator 2314 may indicate that the occupancy is above a second threshold of 90% (e.g., near full capacity). A green alert (not shown in fig. 23) may indicate that the occupancy is below the first threshold of 80%, indicating a higher availability.

Similarly, FIG. 24 shows an expanded view 2400 of GUI 2200 in which row 2308 (corresponding to the state of New York) has been expanded by selecting arrow 2402 (to transition it from a right arrow to a down arrow) to reveal rows having resource data from various hospitals within the state of New York (e.g., NY Presbyteran, NYU Langon, Long Island Jew, Montefire, etc.). As described above, a green alert indicator 2404 may be displayed next to the Buffalo General hospital indicating that the occupancy (74%) for that hospital is below the first threshold 80%. As shown in more detail in fig. 26, it should be understood that the threshold may be customized and configured by the user.

Additionally, alert indicators such as amber alert indicator 2312, red alert indicator 2314, or green alert indicator 2404 may be displayed according to a set of one or more rules or algorithms that may be developed based on current conditions. For example, in the case of a particularly high demand Intensive Care Unit (ICU) bed and ventilator such as a COVID-19 outbreak, an amber or red alert indicator may be displayed alongside a given hospital based on the occupancy of the ICU bed and ventilator, while other resources, such as beds in different wards, are ignored. FIG. 25 shows an expanded view 2500 of the GUI 2200 in which an amber alert 2502 is displayed next to the mountain Sinai Hospital, New York. In one implementation, amber alerts may be displayed based on an ICU occupancy of 92% at tile 2504 and a ventilator occupancy of 81% at tile 2506, regardless of occupancy in the child's ward, observation ward, and the like.

Fig. 26 and 27 show expanded views of the GUI 2200 in which the settings icon 2220 from fig. 22 has been selected to display a settings panel. FIG. 26 shows an expanded view 2600 in which a settings panel 2602 includes various display and control elements that allow a user to customize the dashboard displayed via GUI 2200. In an embodiment, the setup panel 2602 may be expanded or slid out from the right side of the GUI 2200, partially obscuring a dashboard displayed via the GUI 2200. The settings panel 2602 can include a control element for closing the panel, such as a panel close element 2604 indicated by an X, selection of which can cause the control panel to disappear and reveal the full dashboard displayed via the GUI 2200. The settings panel 2602 may also include common control elements, such as a save button 2622, a reset button 2624, a cancel button 2626, and/or an apply button 2628.

The settings panel 2602 may include various portions with different control or display elements. In one embodiment, the GUI 2200 can include an information section 2606 that displays information such as a list of all facilities and the regions, states, divisions, etc. in which those facilities are located. As described below, the informational portion 2606 may be updated to indicate the application of a classification or filtering algorithm that may be customized via the settings panel 2602.

The settings panel 2602 may also include a sort control panel 2608, which may provide control elements that allow a user to interactively define criteria for sorting or ordering data displayed within the GUI 2200. The control elements in the sorting control panel 2608 may be drop-down menus, radio buttons, check boxes, or similar interactive controls that allow the user to specify one or more sorting criteria from a selection of options. For example, a user wishing to sort data displayed in rows of the resource availability dashboard displayed in GUI 2200 from top to bottom in descending order by total number of beds may select "all beds count" in a drop-down menu populated with options for sorting, and/or "descending" in a drop-down menu populated with options for sorting (e.g., ascending or descending order). Indications of any currently defined sorting criteria may also be displayed within the sorting control panel 2608.

The settings panel 2602 may also include a filter control panel 2610, which may provide control elements that allow a user to interactively define criteria for filtering data displayed within the GUI 2200. The filtering control panel 2610 may include a filter selector 2616 for specifying filtering criteria. The filter selector 2616 may be a drop down menu, radio button, check box, or similar interactive control that allows the user to specify one or more filter criteria from a selection of options. The filtering control panel 2610 may also include a logical operator button 2612 that allows a user to specify a plurality of filtering criteria that are appended via one OR more logical operators (e.g., AND, OR, etc.). Similarly, the filter control panel 2610 may also include an add filter button 2620 and/or a remove filter button 2614, which allows the user to add or remove filter criteria.

Where multiple parameters may be associated with a given filter criteria, the filter control panel 2610 may include a parameter list 2618 in which a user may select one or more parameter options associated with the corresponding filter criteria. For example, if the user specifies "alert level" as the filtering criteria in the filter selector 2616, different types of pre-established alerts as described in fig. 25 may be displayed as optional parameters (e.g., key, warning, bed availability, etc.) in the parameter list 2618. Thus, by selecting the parameter "key" in the parameter list 2618, the user can create a dashboard displayed in the GUI 2200 that displays rows corresponding to states, divisions, facilities, etc. that have generated a key (e.g., red) alert, indicating that the occupancy or usage of the resource under consideration has exceeded the second threshold. Fig. 27 shows an exemplary view 2700 of the GUI 2200 with the expanded settings panel 2602 in which the user has selected "alert level" as the filtering criteria in the filter selector 2616 of the filter control panel 2610. In parameter list 2618, warning parameter 2702 and no alert parameter 2704 have been deselected, indicating that the user does not wish to view any rows with amber alerts or no alert rows associated with them (e.g., only rows with red key alerts indicating high occupancy and green alerts indicating bed availability will be displayed). Thus, in information section 2606, once the new filter settings have been applied, hospitals that display amber alerts or no alerts (such as Mount Sinai, North Shore LU, and NYC Belleview) have been disabled (e.g., displayed as gray) in GUI 2200, indicating that they will not be displayed in GUI 2200. FIG. 28 shows an exemplary view 2800 of GUI 2200 in which the filter settings from exemplary view 2700 and FIG. 27 have been applied, so the display shows rows showing only red alerts (corresponding to NY Presbyterian, NYU Lanzone, Long Island Jew and Montefire hospitals) and green alerts (corresponding to Buffalo General, Upstate University, Saraloga and White plants hospitals).

Fig. 29-36 show exemplary views of a third GUI 2900 (e.g., an infectious disease GUI) for viewing resource utilization data at a hospital or hospital system. Like GUIs 1500 and 2200, GUI 2900 may be used to display how critical resources, such as beds, ventilators, etc., are published and utilized in the network and/or hospital network, including displaying indications of which hospitals critical resources may be in short supply and which hospitals may have available resources. While GUIs 1500 and 2200 may display resources in a table layout having columns and rows, GUI 2900 may display data via a modular layout of one or more data tiles that may be positioned adjacent to one another in a variety of different arrangements that may be customized by a user. For example, if one data tile is selected, it may occupy the entire space within GUI 2900; if two data tiles are selected, the two data tiles may be positioned one vertically above the other, as shown in FIG. 33; if three data tiles are selected, the three data tiles may be located as shown in FIG. 35; if four data tiles are selected, the four data tiles may be displayed as a restricted view, as shown in FIG. 29; and so on. In some embodiments, the data tiles may have a fixed size, while in other embodiments, the user may be able to rescale/rescale the data tiles, for example, by selecting a boundary between two tiles and dragging the boundary with an input device such as a mouse. Further, some data tiles may have a fixed size, while other data tiles may be readjustable and/or rescale.

FIG. 29 illustrates an example GUI 2900 in which four data tiles are displayed in a quadrant view, each having different data regarding resource usage and/or availability within a given range. For example, GUI 2900 may show resource occupancy within a single hospital or hospital system, as indicated by range indicator 2902 (e.g., Lakeside hospital). In one embodiment, range indicator 2902 may be a drop down menu that allows a user to select a range of data to display, for example, by selecting a hospital from a list of candidate hospitals.

GUI 2900 may include display elements such as information icon 2904 and settings icon 2906 that, when selected, may display a panel with additional information or selectable options for further filtering of the displayed content. In some embodiments, selecting an informational icon 2904 or a settings icon 2906 may trigger sliding into and partially obscuring a display panel of the GUI 2900 from one side, as shown in fig. 34-36. Selecting the information icon 2904 or the settings icon 2906 may also trigger a display panel that pops up as a separate window or any other type of display panel.

Data tiles included within GUI 2900 may include suitable types of information displays or visualizations, including a list of hospital rooms and resources or resource occupancy associated with the rooms; a list of resources such as beds or ventilators and occupancy rates associated with the resources; a chart or graph showing resource allocation, patient activity, projected activity, or any other data that may be displayed via the chart or graph; patient load information broken down and listed by category; and so on. It should be understood that the examples provided herein are for illustrative purposes and are not to be construed as limiting in any way. Further, the data tile format may evolve over time, with new types of visualizations incorporated into the GUI 2900. Future implementations may include new visualization techniques, video, animation, etc.

For example, in fig. 29, GUI 2900 shows four data tiles displayed on the screen: patient load data block 2908, bed status for CC/CV (ICU, cardiovascular ward) block 2918, patient activity block 2914, and environmental services (EVS) block 2924. The patient load data plot 2908 may include a list of hospital wards 2912 and their locations, the number of patients under test, the number of patients investigated, the number of patients tested positive for codv-19, and the number of ventilators, as indicated by the header line 2910. The hospital administrator may use patient load data block 2908 to determine the location of patients with COVID-19, the number of patients that have been tested, the number of ventilators that have been assigned to a given hospital room, and so forth. Similarly, the bed status for CC/CV block 2918 may include a list of hospital wards having beds for CC/CV with indications of how many beds are in use, how many beds are available, whether the patient has a demotion, transfer or discharge order (e.g., not meeting criteria), number of ventilators, and number of bed freezes. In contrast, the patient activity block 2914 shows a patient activity chart 2916, which may indicate the number of new codv-19 patients that have been confirmed, and the number of tests that have been scheduled, for a given date range. As shown in the patient activity chart 2916, the date range may be extended into the future, and may also display the projected number of new COVID-19 patients and/or the projected number of tests scheduled.

The data tiles may also include graphical elements (e.g., icons) to indicate urgency, availability, warnings, etc. For example, the EVS tile 2924 displays a list of beds for CC/CV with the first two rows displaying a statistical icon 2930 indicating high priority. Additional icons such as a bucket icon 2932, a bed in use icon 2936, and a broom icon 2938 may also be used to indicate that the bed needs to be cleaned, is being cleaned, or is being occupied, respectively. An indication such as highlight box 2940 may indicate a bed that matches a potential hospitalized patient for which a bed has not been assigned.

In some embodiments, an element displayed within GUI 2900 may be selected in order to reveal further information (e.g., data points) related to the element. Fig. 30-32 show exemplary views of GUI 2900 in which additional data is displayed via a pop-up display panel when an input device, such as a mouse, hovers over a particular display element. FIG. 30 shows an exemplary view 3000 of a GUI 2900 in which a user hovers over an alert 3004 that triggers a display panel 3002 with additional information related to the alert 3004. For example, the pop-up display panel 3002 may include a header that explains what the alert indicates, e.g., 4 patients in the Lakeside hospital east 10 ward have tested positive for codv-19. The pop-up display panel 3002 may include information such as a list of patients in the Lakeside hospital east 10 ward that have been tested positive for cody-19, the beds that have been assigned to the patients, and the amount of time these beds have been occupied. Further, the pop-up display panel 3002 may include links to additional data, for example by displaying icons such as icons 3006 or hypertext links such as hypertext links 3008, which when selected may trigger the appearance of the additional display panel.

GUI 2900 may also allow a user to turn alerts on or off, such as when a patient is transferred to or from a given patient room. Fig. 31 shows an exemplary view 3100 of GUI 2900 in which display of a pop-up confirmation box 3102 has been triggered by, for example, selection of an alert, such as alert 3004 in fig. 30, prompting the user to confirm removal of the alert. Additionally, GUI 2900 can display information related to charts or graphics and pop-up display panels. Fig. 32 shows an exemplary view 3200 of GUI 2900 in which a chart showing the number of tests scheduled and confirmed COVID-19 cases over time is displayed in data tile 3202. When the user hovers over the bar chart column 3206, a pop-up display panel 3204 may be displayed to indicate the number of tests scheduled for the day indicated by the bar chart column 3206 and/or positive test results obtained for COVID-19. For example, in fig. 32, the pop-up display panel 3204 indicates that 42 tests are scheduled, with the results of 10 tests being codv-19 positive.

Fig. 33 shows an exemplary view 3300 of GUI 2900 in which resource availability data for a hospital system is displayed, as indicated by scope indicator 2902. For example, a user may have selected the option "system" in a drop down menu with options including one or more individual hospitals in order to view resource availability data that has been aggregated across multiple hospitals. The exemplary view 3300 shows two vertically aligned data tiles, where the current total data tile 3302 shows the total number of COVID-19 patients on the hospital system, and the patient activity tile 3304 shows the number of new tests scheduled and the number of tests whose results are COVID-19 positive. As previously mentioned, the date range in this example extends into the future, showing the projected number of new COVID-19 patients and/or the projected number of tests scheduled over the next two days.

FIG. 34 shows an exemplary view 3400 of a GUI 2900 in which the settings icon 2906 from FIG. 29 has been selected in order to display a settings panel such as settings panel 3402. In an embodiment, the settings panel 3402 includes various display and control elements that allow a user to customize a dashboard displayed via the GUI 2900. The setup panel 3402 may be expanded or slid out from the right side of the GUI 2900, partially blocking a dashboard displayed via the GUI 2900. The settings panel 3402 may also include control elements for closing the panel, such as a panel close element 3404 indicated with an X, selection of which may cause the control panel to disappear and reveal the full dashboard displayed via the GUI 2900. Settings panel 3402 may also include common control elements, such as a save button 3406, a reset button 3408, a cancel button 3410, and/or an apply button 3412.

The settings panel 3402 may include various portions with different control or display elements. In one embodiment, the settings panel 3402 may include interactive control elements for selecting a facility from a pre-populated list of facilities, which may be displayed via a drop-down menu, radio button, check box, or any other similar control element for selecting an option from a list; an option to turn on or off auto-scrolling and/or set an auto-scrolling interval; and/or control elements for selecting one or more categories of information to display as tiles within the GUI 2900, as explained above in fig. 29. For example, the settings panel 3402 shows that four categories of information have been selected to be displayed as tiles arranged in quadrants as shown in FIG. 29: a patient load block 3416, a daily patient count block 3418, a critical care and NP bed block 3420, and a CC plus NP EVS block 3422.

The settings panel 3402 may also include control elements that allow a user to interactively define criteria for sorting, ordering, or filtering data displayed in various tiles within the GUI 2900. The sort, order, or filter control elements may include drop down menus, radio buttons, check boxes, or similar interactive controls that allow the user to specify one or more sort criteria from the selection of options. For example, a user wishing to sort data displayed in rows of tiles displayed in GUI 2900 from top to bottom in a descending order by total number of beds may select corresponding items in a drop down menu populated with sort options and/or select "descending" in a drop down menu populated with options for sort ordering (e.g., ascending or descending). An indication of any currently defined sorting criteria may also be displayed within the settings panel 3402. Similarly, the GUI 2900 may include control elements for filtering resource information displayed in rows of tiles, such as a filter selector, logical operator buttons, add filter and remove filter buttons, a list of filter parameters, and so forth.

As an example of the customization options provided by the settings panel 3402 in fig. 34 discussed above, fig. 35 shows an exemplary view 3500 of the GUI 2900 in which the user has selected three categories of information to display as tiles within the GUI 2900: a scheduled ventilator block 3504, an unused ventilator block 3506, and an order to discontinue ventilator use 3508. Thus, hospital administration personnel may be able to visualize all of the information they need in relation to the assignment or allocation of hospital ventilators in a single dashboard.

Fig. 36 shows an exemplary view 3600 of a GUI 2900 in which an informational icon 2904 from fig. 29 has been selected in order to display a legend panel such as legend panel 3602. The legend panel 3602 may indicate how the different icons displayed in the GUI 2900 may be interpreted. In an embodiment, the legend panel 3602 may be divided into sections corresponding to different types of icons, with interpretations for individual icons displayed next to each icon. For example, legend panel 3602 may include an alert section indicating that an amber alert icon or a red alert icon should explain why; an environmental service (EVS) status section indicating which icons are used to indicate which cleaning or preparation phase the bed is in; and/or a bed status section indicating which icons are used to indicate whether a bed has been allocated, and so on. It should be understood that the elements, sections and icons referred to herein are for illustrative purposes and are not to be construed as limiting.

Fig. 37-44 illustrate an alternative embodiment of a country capacity GUI (e.g., an alternative embodiment of the GUI 2200 of fig. 22-28). The country capacity GUI shown in fig. 37-44 may be similar to GUI 2200, but may include a different title (e.g., country capacity rather than super capacity), the bed availability alert may have a different visual appearance (from triangle to circle), the filter icon moves from NY row to Total row, an extension of the settings panel is displayed, and as shown in fig. 44, a pop-up filter display panel may be displayed in response to the user hovering over the filter icon, where the filter display panel includes the applied filtering (herein, filter key alert level, bed availability), and displays how many facilities are shown and filtered, with the option of clearing the filtering.

The systems, methods, and graphical user interfaces provided herein may improve the accuracy of healthcare resource allocation, sharing, and acquisition in high demand situations where time is limited, such as during an outbreak of an infectious disease where the patient's demand for resources may change exponentially and data acquired on one day may not be applicable on the next day. Because resource utilization may change so quickly, the time it would take to collect data separately from multiple hospitals (especially hospitals that do not typically share data), aggregate and analyze the collected data, and visualize the data using standard methods, may make the data useless by the time it is visualized. By establishing a system that automatically receives data from all hospitals in real-time or near real-time, aggregates this information regardless of the data format, and continuously updates the resource availability dashboard as the data is received, where the dashboard may be presented as a GUI as described herein, the methods of the present disclosure allow healthcare administrators to make informed decisions about critical healthcare issues, such as when and where to transfer patients, when to request new resources (e.g., stock supplies from states or countries, or requests from other hospitals), and when to provide shared resources, thereby improving patient care.

In contrast, in existing systems, when a healthcare administrator or other regulatory agency attempts to request additional resources, transfer a patient or a patient receiving the transfer, or provide for sharing unused resources with another medical facility, errors may occur due to delays in updating resource availability information across multiple wards, facilities, and regions. For example, since hospital resource usage has changed but such changes are not propagated to the manager in a timely manner, new resources requested by the manager may not actually be needed by the time the request is entered and executed, or if such resources are not available because the hospital's resource requirements have changed before the request is entered and executed, shared resources provided by the manager may cause problems. The resource utilization system/GUI addresses this problem by providing a specific dynamically updated list of key resources across facility wards, facilities, hospital networks, regions and country ranges. In this way, the resource availability system and generated GUI as a whole provide an improvement to the capacity of the healthcare system. The present disclosure provides particular ways to improve the capacity of a healthcare system by providing one or more resource availability GUIs that display a dynamically updated list of key resource availabilities. The present disclosure also provides specific improvements to the manner in which computers operate by aggregating key resource availability information for multiple individual facilities in a location and updating the key resource availability information in real-time, which may eliminate the need for users to have to navigate through multiple different data files, manually update information as availability changes, etc., thereby increasing the efficiency with which users operate computers.

Further, a hospital may not be configured to share critical resource data in real-time, even across different wards of the hospital. Thus, existing methods of resource availability determination require manual collection of data (e.g., visually inspecting bed occupancy and ventilator usage for each room) and aggregation in a spreadsheet or other document, and also require manual updating. These systems are not available for automatically pulling data from multiple wards and multiple facilities, and then aggregating the pulled data into a visually clear format, where healthcare decisions can be quickly made simply by sliding at a GUI, as described in embodiments herein. Additionally, different facilities may have different data sharing protocols, and the need to comply with HIPAA/patient information sharing laws means that different facilities may provide data in different formats (e.g., HL7 messages and flat files), and existing systems are unable to automatically aggregate these different formats into a single set of dashboards that can be visualized via a GUI, where the dashboards are automatically updated whenever new data is received, as described herein.

The resource availability GUI described herein provides a specific way to display a limited set of information (key resource availability information) to a user, rather than displaying a generic index on a computer using conventional user interface methods, requiring the user to step through many layers of menu options to arrive at the desired data, or to embed the desired data within all hospital data. Thus, the user's experience with the computer may be improved and more efficient.

Further, by displaying a limited set of information via a resource availability GUI as described herein, the operation of a computing device that collects and presents data for display may be improved by reducing the processing requirements of the computing device, thereby increasing the efficiency of the computing device. For example, only certain key resource availability and allocation information may be displayed, which results in a limited amount of received data being processed, which may improve the efficiency of the computing device. Furthermore, because the data is processed in real-time and updates to the resource availability GUI are continuously made as the data is received, excess processing lag that may occur if updates are made at predefined discrete points in time may be reduced, which may improve the efficiency of the computing device.

Embodiments described herein may allow for various types of data to be retrieved/received from different locations and systems (e.g., different hospitals, hospital networks, etc.), and processed to populate a resource availability GUI as described herein in real-time or near real-time. The system described herein may be configured to continue updating the resource availability GUI even if the hospital or network experiences a lag in data collection or reporting, or data is unexpectedly unavailable from a given institution for other reasons over a period of time. For example, data from other organizations may continue to be reported even if data from other organizations is not available. Further, in some examples, where current resource availability data for a given organization is not available, the systems described herein may use previous data from that organization to project resource availability and report the projected resource availability via the resource availability GUI. In so doing, real-time reporting of data may be maintained.

A resource utilization server included as part of a collaborative resource utilization system as described herein can provide high-speed data processing that allows real-time or near real-time updates to different resource availability GUIs. For example, the resource utilization server may be configured to update the critical resources GUI every 30 seconds rather than every 15 minutes or longer as in some existing systems. To accomplish this, the resource utilization server may be configured with a parser that sends a data reception acknowledgement (e.g., HL7 acknowledgement) before processing the received packet/message, and may check/reject the packet/message before processing.

Further, the resource utilization server can be configured to derive hospital composition information (e.g., bed inventory, ventilator usage information) by pulling data from the EMRs and/or by deriving composition information from messages/packets sent and received by the resource utilization server. For example, the message may ask for specific information (e.g., bed inventory), and the resource utilization server may compute the composition information from the response, e.g., by combing the data/message to pull the information. This approach may avoid the need for upstream users or systems (e.g., at a hospital) to fill out forms (such as bed major forms) and send updates, which may allow for faster retrieval of information.

As described herein, a technical effect of presenting hospital resource utilization information for a hospital system via a GUI is that hospital administrators and/or healthcare providers can quickly make decisions regarding resource sharing/reallocation, new equipment orders, patient transfers, etc., so that patient care can be improved. Furthermore, the use of simplicity, intuitiveness, and scalability facilitates rapid deployment across hospital networks of any scale.

Embodiments of a method are provided, which include: receiving first data from a first medical facility, the first data received via a first data flow process and/or in a first format; receiving second data from a second medical facility, the second data received via a second data flow process and/or in a second format; processing the first data and the second data to generate one or more resource availability Graphical User Interfaces (GUIs); and outputting the one or more resource availability GUIs for display on a display device. In a first embodiment of the method, first data is received from a first medical facility in an HL7 message format via HTTPS/TCP. In a second embodiment of the method, the second embodiment optionally includes the first embodiment, receiving second data from the second medical facility in one or more flat files via SFTP. In a third embodiment of the method, the third embodiment optionally includes one or both of the first and second embodiments, each of the first and second data processed to determine a per-patient-bed occupancy of the first medical facility and a per-patient-bed occupancy of the second medical facility, respectively. In a fourth embodiment of the method, the fourth embodiment optionally includes one or more or each of the first to third embodiments, processing each of the first and second data to determine a count of occupied beds, a count of frozen beds, a count of unoccupied beds, and a count of negative pressure beds for each patient room of the first medical facility and for each patient room of the second medical facility. In a fifth embodiment of the method, the fifth embodiment optionally includes one or more or each of the first to fourth embodiments, processing each of the first and second data to determine a medical device count of the first medical facility and a medical device count of the second medical facility, respectively. In a sixth embodiment of the method, the sixth embodiment optionally includes one or more or each of the first through fifth embodiments, receiving and processing the first data in real-time, and wherein the second data is received and processed in near real-time. In a seventh embodiment of the method, the seventh embodiment optionally includes one or more or each of the first to sixth embodiments, the first medical facility is one of a plurality of first medical facilities configured to transmit the first data in the first format, and wherein the second medical facility is one of a plurality of second medical facilities configured to transmit the second data in the second format. In an eighth embodiment of the method, the eighth embodiment optionally includes one or more or each of the first to seventh embodiments, processing the first data from each first medical facility and the second data from each second medical facility to generate one or more resource availability GUIs. In a ninth embodiment of the method, the ninth embodiment optionally includes one or more or each of the first through eighth embodiments, the one or more resource availability GUIs including a first resource availability GUI configured to display resource availability at a country level, a region level, and a facility level in the hospital network. In a tenth embodiment of the method, the tenth embodiment optionally includes one or more or each of the first through ninth embodiments, the one or more resource availability GUIs including a second resource availability GUI configured to display resource availability at a country level, a regional level, and a facility level across multiple hospital networks and/or multiple individual hospitals. In an eleventh embodiment of the method, the eleventh embodiment optionally includes one or more or each of the first through tenth embodiments, the one or more resource availability GUIs include a third resource availability GUI configured to display resource availability and patient load for a particular illness across one or more hospitals. In a twelfth embodiment of the method, the twelfth embodiment optionally includes one or more or each of the first through eleventh embodiments, the particular disorder is covd-19, and wherein the third resource availability GUI is configured to display a count of patients undergoing a covd-19 test, a count of patients determined to be covd-19 positive, and a count of patients determined to be still under investigation for covd-19. In a thirteenth embodiment of the method, the thirteenth embodiment optionally includes one or more or each of the first through twelfth embodiments, the particular disorder is COVID-19, and wherein the third resource availability GUI is configured to display a graphic showing a past, current, and predicted number of scheduled COVID-19 tests, and a past, current, and predicted number of new COVID-19 patients. In a fourteenth embodiment of the method, the fourteenth embodiment optionally includes one or more or each of the first through thirteenth embodiments, the one or more resource availability GUIs are configured to display the resource availability alert in response to determining, based on the first data and/or the second data, that the resource availability has fallen below a threshold level.

An embodiment of a system comprises: a display; and a computing device operably coupled to the display and storing instructions executable to: outputting, to the display, a Graphical User Interface (GUI) comprising one or more of a per-ward count, a medical device utilization count, and a disease count for each of a plurality of medical facilities, the one or more of the per-ward count, the medical device utilization count, and the disease count determined based on data transmitted from each of the plurality of medical facilities, wherein the data comprises data transmitted in a first format from a first medical facility and data transmitted in a second format from a second medical facility. In a first embodiment of the system, the per-patient bed count comprises an occupancy per patient bed, and the GUI is configured to display a graphical representation of each occupancy per patient bed, each graphical representation configured to change visual appearance if the corresponding occupancy of the bed increases above a threshold rate. In a second embodiment of the system, the second embodiment optionally includes the first embodiment, the medical device utilization count comprises a ventilator occupancy rate, and the GUI is configured to display a graphical representation of each ventilator occupancy, each graphical representation configured to change visual appearance if the corresponding ventilator occupancy increases above a threshold rate. In a third embodiment of the system, the third embodiment optionally includes one or both of the first and second embodiments, the first format comprises an HL7 message, and the second format comprises a flat file. In a fourth embodiment of the system, the fourth embodiment optionally includes one or more or each of the first to third embodiments, the instructions executable to update one or more of a per-ward count, a medical device utilization count, and a disease count as data sent from each medical facility of the plurality of medical facilities changes.

An embodiment of the method comprises: determining whether a patient suspected of having a disease is positive, negative, or under investigation for the disease based on one or more test results of one or more tests for the disease included in a data stream from a medical facility and further based on an amount of time since the one or more tests were conducted; and updating one or more resource availability Graphical User Interfaces (GUIs) based on the determination. In a first embodiment of the method, the determining comprises: if the patient has a negative test result for the current test without a previous positive test result, indicating that the patient is negative for the disease in response to a first threshold amount of time having elapsed since the current test was performed, otherwise indicating that the patient is under investigation. In a second embodiment of the method, the second embodiment optionally includes one or both of the first embodiment and the second embodiment, the determining comprising: if the patient has an inconclusive test result for the current test without a previous positive test result, then the patient is indicated as being under investigation until a negative test result is received or until a first threshold amount of time has elapsed since the current test was performed, and then the patient is indicated as negative. In a fourth embodiment of the method, which optionally includes one or more or each of the first to third embodiments, the determining comprises: if the patient has at least one previous positive test result, indicating that the patient is positive for the disease until: a) a second threshold amount of time has elapsed since a first negative test result following a previous positive test result; or b) receiving two negative test results after a previous positive test result, the two negative tests being conducted within at least a third threshold amount of time between the two tests. In a fifth embodiment of the method, the fifth embodiment optionally including one or more or each of the first through fourth embodiments, the updating the one or more resource availability GUIs comprising: removing the patient from the positive count or the count of the person under investigation in response to indicating that the patient is negative; adding the patient to a positive count in response to indicating that the patient is positive; and adding the patient to the person under investigation in response to indicating that the patient is under investigation. In a sixth embodiment of the method, the sixth embodiment optionally includes one or more or each of the first through fifth embodiments, the one or more resource availability GUIs including a first resource availability GUI in which a positive count and a count of people under investigation are displayed for each of a plurality of statistical regions. In a seventh embodiment of the method, which optionally includes one or more or each of the first through sixth embodiments, the first resource availability GUI is configured to display a positive count and a survey person count by state and/or hospital in response to a user request. In an eighth embodiment of the method, which optionally includes one or more or each of the first through seventh embodiments, the first resource availability GUI is configured to display the count per patient room bed and/or bed utilization and the medical device utilization count and/or medical device utilization for each of a plurality of statistical regions. In a ninth embodiment of the method, the ninth embodiment optionally includes one or more or each of the first through eighth examples, the first resource availability GUI configured to display the per-ward bed count and/or bed utilization and the medical device utilization count and/or medical device utilization per state and/or hospital in response to a user request. In a tenth embodiment of the method, the tenth embodiment optionally includes one or more or each of the first through ninth embodiments, the first resource utilization dashboard configured to display an alert in response to the per-patient bed utilization or medical device utilization exceeding a respective threshold. In an eleventh embodiment of the method, which optionally includes one or more or each of the first through tenth embodiments, updating the one or more resource availability GUIs comprises: in response to indicating that the patient is positive, the patient is added as a new diagnosed patient to a histogram showing a past, present, and predicted number of scheduled disease tests, and a past, present, and/or predicted number of new diagnosed patients. In a twelfth embodiment of the method, the twelfth embodiment optionally includes one or more or each of the first through eleventh embodiments, updating each of the first, second, and third threshold amounts of time based on government agency guidelines. In a thirteenth embodiment of the method, the thirteenth embodiment optionally includes one or more or each of the first through twelfth embodiments, each of the first, second, and third threshold amounts of time being user configurable.

Another embodiment of the method comprises: receiving positive test results for a patient suspected of having a disease from a data stream from a medical facility, and updating one or more resource availability Graphical User Interfaces (GUIs) to include the patient in a disease positive count; and if a negative test result for the patient is received in a data stream from the medical facility after the positive test result, updating the one or more resource availability GUIs to remove the patient from the disease positive count only if a first threshold amount of time has elapsed since the negative test result was received or the negative test result is a second negative test result that is subsequent to the first negative result, wherein the second negative test result is at least a second threshold amount of time after the first negative result. In a first embodiment of the method, the one or more resource availability GUIs include a first resource availability GUI configured to display resource availability at a country level, a region level, and a facility level in the hospital network. In a second embodiment of the method, the second embodiment optionally includes the first embodiment, the one or more resource availability GUIs comprises a second resource availability GUI configured to display resource availability at a country level, a region level, and a facility level across multiple hospital networks and/or multiple individual hospitals. In a third embodiment of the method, the third embodiment optionally includes one or both of the first and second embodiments, the one or more resource availability GUIs includes a third resource availability GUI configured to display resource availability and disease positive counts across one or more hospitals. In a fourth embodiment of the method, the fourth embodiment optionally includes one or more or each of the first through third embodiments, the disease is COVID-19, and wherein the third resource availability GUI is further configured to display a survey personnel count for patients determined to still be under survey for COVID-19. In a fifth embodiment of the method, the fifth embodiment optionally includes one or more or each of the first through fourth embodiments, the one or more resource availability GUIs are configured to display a resource availability alert in response to determining that the resource availability has fallen below a threshold level.

An embodiment of a system comprises: a display; and a computing device operably coupled to the display and storing instructions executable to: outputting to the display a graphical user interface comprising positive counts for a disease and surveyed person counts for the disease displayed for each of a plurality of statistical regions, states, hospital networks, hospitals, and/or hospital wards; receiving a plurality of test results for the disease from a plurality of data streams from a plurality of medical facilities; and in response to one of the plurality of test results being a negative test result for the patient counted in the positive count, updating the positive count only if a first threshold amount of time has elapsed since the negative test result was received or the negative test result is a second negative test result that is subsequent to the first negative result, wherein the second negative test result is at least a second threshold amount of time after the first negative result.

An embodiment of the method comprises: receiving real-time data associated with a plurality of ventilators; for each ventilator of the plurality of ventilators, determining a ventilator state based on one or more of a ventilation start time, a ventilation stop time, a ventilator type, and a ventilator position, the one or more of the ventilation start time, the ventilation stop time, the ventilator type, and the ventilator position determined from the real-time data; and updating one or more resource availability Graphical User Interfaces (GUIs) based on the ventilator state. In a first embodiment of the method, determining the ventilator state comprises determining: a) whether a ventilation start time has been indicated; b) whether ventilatory arrest time has not been indicated; c) whether a ventilation start time has been indicated after a ventilation stop time; and d) whether the ventilator is an invasive ventilator; and if one of a), d) and b) or c) is true for the respective ventilator, indicating that the ventilator state is in use and that the ventilator is an invasive ventilator. In a second embodiment of the method, the second embodiment optionally includes the first embodiment, receiving real-time data associated with a plurality of ventilators comprises receiving real-time data from the plurality of ventilators or from one or more electronic medical records databases, and wherein updating the one or more resource availability GUIs based on the ventilator status comprises updating a ventilator occupancy displayed on the one or more resource availability GUIs. In a third embodiment of the method, which optionally includes one or both of the first and second embodiments, the method further comprises displaying, via the one or more resource availability GUIs, a graphical representation of ventilator occupancy configured to change visual appearance in response to the ventilator occupancy increasing above a threshold rate. In a fourth embodiment of the method, which optionally includes one or more or each of the first through third embodiments, receiving real-time data associated with a plurality of ventilators includes receiving real-time data from a plurality of ventilators located at a plurality of different medical facilities. In a fifth embodiment of the method, which optionally includes one or more or each of the first through fourth embodiments, receiving real-time data associated with a plurality of ventilators includes receiving an HL7 message. In a sixth embodiment of the method, the sixth embodiment optionally includes one or more or each of the first through fifth embodiments, the one or more resource availability GUIs include a first resource availability GUI configured to display resource availability at a national level, a regional level, and a facility level in the hospital network. In a seventh embodiment of the method, the seventh embodiment optionally includes one or more or each of the first through sixth embodiments, the one or more resource availability GUIs include a second resource availability GUI configured to display resource availability at a country level, a regional level, and a facility level across multiple hospital networks and/or multiple individual hospitals. In an eighth embodiment of the method, the eighth embodiment optionally includes one or more or each of the first through seventh instances, the one or more resource availability GUIs including a third resource availability GUI configured to display resource availability and patient load for a particular illness across one or more hospitals. In a ninth embodiment of the method, the ninth embodiment optionally includes one or more or each of the first through eighth embodiments, the particular disorder is codv-19, and wherein the third resource availability GUI is configured to display a count of patients undergoing a codv-19 test, a count of patients determined to be codv-19 positive, and a count of patients determined to be still under investigation for codv-19. In a tenth embodiment of the method, the tenth embodiment optionally includes one or more or each of the first through ninth embodiments, the resource availability includes a ventilator count and/or ventilator occupancy in use, each ventilator count and/or ventilator occupancy in use is updated based on a ventilator status, and the resource availability further includes a count of occupied beds, a count of frozen beds, a count of unoccupied beds, and a count of negative pressure beds for each patient room of the plurality of medical facilities.

An embodiment of a system comprises: a display; and a computing device operably coupled to the display and storing instructions executable to: receiving real-time data associated with a plurality of ventilators; determining, for each ventilator of the plurality of ventilators, whether the ventilator is currently in use based on the real-time data; outputting, to a display, a Graphical User Interface (GUI) including respective ventilator occupancy rates for hospital wards, hospitals, hospital networks, states, regions, and/or countries, each ventilator occupancy rate determined based on a number of ventilators determined to be currently in use and a location of each ventilator. In a first embodiment of the system, to determine whether the ventilator is currently in use, instructions can be executed to determine: a) whether a ventilation start time of the ventilator has been indicated; b) whether a ventilatory arrest time of the ventilator has not been indicated; and c) whether a ventilation start time of the ventilator has been indicated after a ventilation stop time; and wherein if one of a) and b) or c) is true, the instructions can be further executed to determine whether the ventilator is currently in use. In a second embodiment of the system, the second embodiment optionally includes the first embodiment, the instructions being executable to determine a position of each ventilator based on the real-time data. In a third embodiment of the system, optionally including one or both of the first and second embodiments, the instructions can be executed to update each respective ventilator occupancy in real-time as real-time data is received. In a fourth embodiment of the system, the fourth embodiment optionally includes one or more or each of the first through third embodiments, the GUI further including respective bed occupancy for one or more hospital rooms, one or more hospitals, one or more hospital networks, one or more states, one or more regions, and/or one or more countries. In a fifth embodiment of the system, the fifth embodiment optionally includes one or more or each of the first through fourth embodiments, the GUI configured to display the resource availability alert in response to determining that the ventilator occupancy and/or the bed occupancy is above the respective threshold level.

An embodiment of the method comprises: receiving real-time data associated with a plurality of ventilators; for each ventilator of the plurality of ventilators, determining, based on the real-time data, whether the ventilator is currently in use in a defined geographic area; and outputting a Graphical User Interface (GUI) to the display, the GUI including a ventilator occupancy for a defined geographic area, the ventilator occupancy for the defined geographic area determined based on whether each ventilator is currently being used in the defined geographic area. In a first embodiment of the method, the determining comprises determining, for each ventilator: a) whether a ventilation start time has been indicated; b) whether ventilatory arrest time has not been indicated; c) whether a ventilation start time has been indicated after a ventilation stop time; and d) whether the ventilator is located in a defined geographic area; and if one of a), d) and b) or c) is true for the respective ventilator, the method includes indicating that the ventilator is currently in use in the defined geographic area. In a second embodiment of the method, the second embodiment optionally includes the first embodiment, the method further comprising displaying, via the GUI, a graphical representation of the occupancy rate of the ventilator, the graphical representation configured to change visual appearance in response to the occupancy rate of the ventilator increasing above a threshold rate.

As used herein, an element or step recited in the singular and proceeded with the word "a" or "an" should be understood as not excluding plural said elements or steps, unless such exclusion is explicitly recited. Furthermore, references to "one embodiment" of the present invention are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features. Moreover, unless explicitly stated to the contrary, embodiments that "comprise," "include," or "have" an element or a plurality of elements having a particular property may include additional such elements not having that property. The terms "including" and "in. Furthermore, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to impose numerical requirements or a particular positional order on their objects.

This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the relevant art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those of ordinary skill in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims.