Systems and methods for generating synthetic data for hospital patient flow simulation

Abstract

A system and method generate synthetic data simulating patient flow in a hospital for conducting simulations to provide hospital operations analysis. The method includes: populating a hospital configuration file by specifying hospital parameters to provide hospital-specific data and by specifying simulation criteria; populating an arrival configuration file by specifying arrival parameters to arrival modules, wherein each arrival module includes a corresponding constraint and is configured to generate a base waveform to capture a corresponding arrival pattern or generate a schedule; generating patient trajectories for each arrival module based on the base waveform or schedule and the hospital-specific data from the hospital configuration file; integrating the patient trajectories to provide integrated patient trajectories including synthetic data specific to patient flow in the hospital; and applying analysis algorithms to the integrated patient trajectories to implement realistic scenario simulations for implementing staff planning, resource allocation, and / or simulated remediation strategies.

Description

Background Technology

[0001] The use of analytics has increased over the past decade to help improve hospital operations, including patient care and treatment. Hospital patient flow simulations can often be used to predict key operational conditions, such as bottlenecks and staffing needs. However, calibrating patient flow simulations implemented by artificial intelligence (AI) requires a significant amount of data from the hospital, which is often difficult to obtain. Additionally, patient flow simulations can be used to test possible scenarios (i.e., "what if" scenarios), but this also requires finding sufficient data in the historical records describing such scenarios or creating data from scratch.

[0002] Recently, the role of synthetic data in AI research has expanded. This is especially true for clinical data, where privacy restrictions and heterogeneous data systems pose obstacles to acquiring data sufficient to adequately train AI clinical analysis, thus impairing the performance and quality of AI clinical analysis results. However, most research focuses on the representation of clinical data, with few attempts to generate realistic operational and procedural clinical data. Similarly, the more realistic the data, the better the capabilities of AI clinical analysis.

[0003] For example, the Patient Flow Capacity Suite (PFCS) is a cloud-based logistics management solution available from Royal Philips in the Netherlands. This cloud-based solution provides hospital operational analytics to enable situational awareness, staffing planning, resource allocation, and more to improve patient care and treatment. Since no two hospitals are the same, many PFCS analyses require historical data from each hospital for calibration and accurate prediction. However, historical data may not be readily available from hospitals and may be incomplete or insufficient for proper training, which hinders the deployment of this solution.

[0004] Therefore, it would be advantageous if realistic synthetic data could be reliably created for the calibration, training, and scenario testing of AI analytics algorithms, including machine learning algorithms, without relying on actual data obtained from hospitals. Such data would improve the functionality of AI analytics algorithms, which in turn would provide crucial capabilities for hospital flow simulation technology. Summary of the Invention

[0005] According to a representative embodiment, a method is provided for generating synthetic data related to occupancy and patient flow in a hospital to simulate patient flow within the hospital. The method includes: providing hospital-specific data by specifying multiple hospital parameters and populating hospital profiles by specifying simulation criteria; the hospital-specific data includes: patient data, ward capacity data indicating the capacity of at least some wards (e.g., one ward, and preferably all wards) in the hospital, and ward occupancy data indicating the occupancy of each ward in the hospital; the simulation criteria include at least the simulation duration, ward capacity data indicating the capacity of wards in the hospital, and ward occupancy data indicating the occupancy of the wards in the hospital; and populating multiple arrival profiles by specifying multiple arrival parameters for each arrival module, wherein each arrival module includes at least one corresponding constraint and is configured... The system is configured to generate a basic waveform based on at least one corresponding constraint to capture a corresponding arrival pattern, or to generate a timetable based on at least one corresponding constraint; generate a patient trajectory for each of a plurality of arrival modules based on the basic waveform or the timetable from the corresponding arrival profile and based on the hospital-specific data from the hospital profile; integrate the patient trajectories from the plurality of arrival modules to provide an integrated patient trajectory, the integrated patient trajectory including synthetic data of the patient flow specific to the hospital; and apply AI analytics algorithms to the integrated patient trajectory to achieve realistic scenario simulation, personnel planning, resource allocation, and / or simulated remedial strategies to alleviate the hospital's overcrowding problem.

[0006] According to a representative embodiment, a computer-implemented method is described for generating synthetic data related to occupancy and patient flow in a hospital to simulate patient flow within the hospital, the method comprising: The hospital configuration file is populated by specifying multiple hospital parameters to provide hospital-specific data and by specifying simulation criteria; the hospital-specific data includes at least one of the following: patient data, ward capacity data indicating the capacity of at least one of a plurality of wards in the hospital, and ward occupancy data indicating the occupancy of at least one of the plurality of wards; the simulation criteria include at least the simulation duration, the ward capacity data indicating the capacity of wards in the hospital, and the ward occupancy data indicating the occupancy of the wards in the hospital. Additionally, in at least some embodiments, the method includes: populating multiple arrival profiles by specifying multiple arrival parameters for multiple arrival modules, wherein the multiple arrival modules include at least one constraint, and the multiple arrival modules are configured to generate a basic waveform based on at least one corresponding constraint to capture a corresponding arrival pattern, or to generate a schedule based on at least one corresponding constraint; additionally, generating at least one patient trajectory for at least one of the multiple arrival modules based at least on the basic waveform or the schedule from the respective arrival profile and based on the hospital-specific data from the hospital profile; integrating the at least one patient trajectory from the multiple arrival modules to provide an integrated patient trajectory, the integrated patient trajectory including synthetic data of the patient flow specific to the hospital; and applying an analysis algorithm to the integrated patient trajectory to provide a realistic scenario simulation for implementing personnel planning, resource allocation, and / or simulating remedial strategies in hospital workflows.

[0007] According to a representative embodiment, a non-transient computer-readable storage medium or a computer-readable storage medium stores instructions for generating synthetic data relating to occupancy and patient flow in a hospital to simulate patient flow within the hospital. When executed by a processor, the instructions cause the processor to perform the following operations: providing hospital-specific data by specifying hospital parameters and populating a hospital profile by specifying simulation criteria; the hospital-specific data including: patient data, ward capacity data indicating the capacity of at least one ward among a plurality of wards in the hospital, and ward occupancy data indicating the occupancy of at least one ward among the plurality of wards; the simulation criteria including at least the simulation duration, the ward capacity data indicating the capacity of wards in the hospital, and the ward occupancy data indicating the occupancy of the wards in the hospital; and populating multiple arrival profiles by specifying multiple arrival parameters for multiple arrival modules, wherein each arrival module includes at least one corresponding constraint and is configured to generate data based on the at least one corresponding constraint. The system generates a basic waveform to capture the corresponding arrival pattern, or is configured to generate a timetable based on the at least one corresponding constraint; generates a patient trajectory for at least one of the plurality of arrival modules (preferably for each arrival module) based on the basic waveform or the timetable from the corresponding arrival profile and based on the hospital-specific data from the hospital profile; integrates the patient trajectories from the plurality of arrival modules to provide an integrated patient trajectory, the integrated patient trajectory including synthetic data specific to the patient flow in the hospital (e.g., indicating the patient flow); and applies an analysis algorithm to the integrated patient trajectory to achieve a realistic scenario simulation for implementing personnel planning, resource allocation, and / or simulating remedial strategies to alleviate the hospital's overcrowding problem.

[0008] According to a representative embodiment, a system is provided for generating synthetic data related to occupancy and patient flow in a hospital to simulate patient flow within the hospital. The system includes: a processor; a user interface configured to enable interaction between a user and the processor; and a memory connected to the processor and storing instructions. When executed by the processor, the instructions cause the processor to perform the following operations: providing hospital-specific data by specifying hospital parameters and populating a hospital profile by specifying simulation criteria; the hospital-specific data including: patient data, ward capacity data indicating the capacity of at least one ward among a plurality of wards in the hospital, and ward occupancy data indicating the occupancy of at least one ward among the plurality of wards; the simulation criteria including at least the simulation duration, the ward capacity data indicating the capacity of wards in the hospital, and the ward occupancy data indicating the occupancy of the wards in the hospital; and populating multiple arrival profiles by specifying multiple arrival parameters for multiple arrival modules, wherein each arrival module includes at least one corresponding constraint and is configured to... The system is configured to generate a basic waveform based on at least one corresponding constraint to capture a corresponding arrival pattern, or to generate a timetable based on at least one corresponding constraint; generate a patient trajectory for each of the plurality of arrival modules based on the basic waveform or the timetable from the corresponding arrival profile and based on the hospital-specific data from the hospital profile; integrate the patient trajectories from the plurality of arrival modules to provide an integrated patient trajectory, the integrated patient trajectory including synthetic data of the patient flow specific to the hospital; and apply an analysis algorithm to the integrated patient trajectory to achieve a realistic scenario simulation for implementing personnel planning, resource allocation, and / or simulating remedial strategies to alleviate the hospital's overcrowding problem. Attached Figure Description

[0009] The exemplary embodiments can be best understood by reading the following detailed description in conjunction with the accompanying drawings. It should be emphasized that the various features are not necessarily drawn to scale. In fact, dimensions may be arbitrarily increased or decreased for clarity of discussion. Like reference numerals denote like elements, as long as applicable and practical.

[0010] Figure 1 This is a simplified block diagram of a system, according to a representative embodiment, for generating synthetic data relating to occupancy and patient flow in a hospital to simulate patient flow within a hospital.

[0011] Figure 2 This is a flowchart of a method for simulating patient flow within a hospital, based on a representative embodiment, to generate synthetic data relating to occupancy and patient flow in a hospital.

[0012] Figure 3A This is a flowchart of a method for generating a patient trajectory for simulating emergency department admission, based on a representative embodiment.

[0013] Figure 3B This is a flowchart of a method for generating a patient trajectory to simulate direct hospital admission, based on a representative embodiment.

[0014] Figure 3C This is a flowchart of a method for generating patient trajectories to simulate hospital admission to a transfer center, based on a representative embodiment.

[0015] Figure 3D This is a flowchart of a method for generating patient trajectories for simulating surgical center operations, according to a representative embodiment. Detailed Implementation

[0016] In the following detailed description, representative embodiments disclosing specific details are set forth for purposes of explanation and not limitation, in order to provide a thorough understanding of embodiments according to this teaching. Descriptions of known systems, apparatuses, materials, methods of operation, and methods of manufacture may be omitted to avoid obscuring the description of representative embodiments. Nevertheless, systems, apparatuses, materials, and methods that are within the scope of understanding of those skilled in the art are also within the scope of this teaching and may be used according to representative embodiments. It should be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. Defined terms are supplementary to their scientific and technical meanings as commonly understood and accepted in the art as described in this teaching.

[0017] It should be understood that although the terms "first," "second," "third," etc., may be used herein to describe various elements or components, these elements or components should not be limited by these terms. These terms are only used to distinguish one element or component from another. Therefore, without departing from the teachings of the inventive concept, the first element or component discussed below may also be referred to as the second element or component.

[0018] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. The singular forms of the terms “a,” “an,” and “the” as used in the specification and appended claims are intended to include both the singular and plural forms unless the context clearly specifies otherwise. Furthermore, when the terms “comprising” and / or “including” and / or similar terms are used herein, such terms specify the presence of the stated features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or groups thereof. The term “and / or” as used herein includes any and all combinations of one or more associated listed items.

[0019] Unless otherwise stated, when an element or component is referred to as "connected to," "coupled to," or "adjacent to" another element or component, it should be understood that the element or component can be directly connected to or coupled to the other element or component, or that intermediate elements or components may be present. That is, these and similar terms cover situations where one or more intermediate elements or components may be used to connect two elements or components. However, when an element or component is referred to as "directly connected to" another element or component, this only covers situations where two elements or components are connected to each other without any intermediate or intermediary elements or components.

[0020] As used in the specification and appended claims, the terms "approximately" and "roughly" mean, in addition to their ordinary meaning, an acceptable limitation or extent. For example, "approximately 2 MHz" means that a person skilled in the art would consider the signal to be 2 MHz within a reasonable measurement. Similarly, as used in the specification and appended claims, the term "substantially" means, in addition to its ordinary meaning, within an acceptable limitation or extent. For example, the term "substantially simultaneously" means that a person skilled in the art would consider the events to occur simultaneously.

[0021] In view of the foregoing, this disclosure is therefore intended to offer one or more advantages, as specifically pointed out below, through its various aspects, embodiments, and / or specific features or sub-components. Example embodiments disclosing specific details are set forth for purposes of explanation and not limitation in order to provide a thorough understanding of embodiments based on this teaching. However, other embodiments consistent with this disclosure that depart from the specific details disclosed herein remain within the scope of the appended claims. Additionally, descriptions of well-known apparatuses and methods may be omitted so as not to obscure the description of the example embodiments. Such methods and apparatuses are also within the scope of this disclosure.

[0022] Typically, at least in some instances, various embodiments provide software platforms (e.g., data synthesizers) that allow the creation of user-specified synthetic data. These platforms can be used to improve the calibration and training of AI analytics algorithms, and to improve scenario testing and prediction (e.g., PFCS census prediction) through calibrated and trained AI analytics algorithms. Users can create realistic arrival and statistics using only qualitative knowledge of anticipated hospital operational data. This is possible because the data synthesizer is constructed using realistic operational constraints derived from specialized data and knowledge. The data synthesizer can also be used to create operational datasets for algorithm development purposes and potentially combine them with deanonymized clinical data to generate semi-synthetic comprehensive hospital datasets.

[0023] For example, embodiments generate calibration and training data for patient flow simulation technologies, as well as realistic hospital data for testing "what if" scenarios (e.g., "what if the intensive care unit (ICU) has capacity" or "what if the number of people arriving at the emergency department doubles on Friday"). Additionally, embodiments can generate specific, customized operational and clinical datasets with additional privacy protections.

[0024] Creating synthetic data requires an accurate description of several key processes. These key processes include, for example, configuring arrival patterns, patient stay patterns, and other synthetic inputs, while also adhering to realistic hospital constraints. Parameterizing and integrating these key processes is challenging. The embodiments described in this paper outline how parameterization can be accomplished, focusing on emergency arrivals, direct admission arrivals, transfer patient arrivals, and scheduled surgical arrivals. The entire framework is flexible because it can be applied to different hospital configurations (e.g., different wards, different numbers of beds, etc.). Hospital constraints are applied to ensure the data maintains a realistic hospital representation.

[0025] Figure 1 This is a simplified block diagram of a system, according to a representative embodiment, for generating synthetic data relating to occupancy and patient flow in a hospital to simulate patient flow within a hospital.

[0026] refer to Figure 1 System 100 includes a workstation 105 for implementing and / or managing the processes described herein. Workstation 105 includes a processor 120, memory 130, a user interface 122, and a display 124. Memory 130 stores instructions executable by processor 120. When executed, these instructions cause processor 120 to implement one or more processes for automatically generating synthetic data related to occupancy and patient flow in the hospital. For illustrative purposes, memory 130 is shown as including software modules, each including a set of instructions executable by processor 120 corresponding to the associated capabilities of system 100.

[0027] Synthetic data can be electronic data that can be used as input for AI algorithms used in planning, testing, and medical treatment where real-world data is absent or insufficient to perform meaningful simulations and / or predictions. Furthermore, in embodiments, synthetic data can be partially derived from actual clinical data without compromising patient privacy associated with that data. Because synthetic data is entirely electronic, the generation of synthetic data and / or patient trajectories including it cannot be performed in human thought. Moreover, generating synthetic data represents an improvement in the field of computer-implemented simulation and modeling, where conventional systems rely on real-world or modeling data that cannot adequately represent the desired dataset.

[0028] Processor 120 represents one or more processing devices and may be implemented using any combination of hardware, software, firmware, hardwired logic circuitry, or a combination thereof, from a general-purpose computer, central processing unit (CPU), digital signal processor (DSP), graphics processing unit (GPU), tensor processing unit (TPU), computer processor, microprocessor, state machine, programmable logic device, field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or a combination thereof. Any processor or processing unit herein may include multiple processors, parallel processors, or both. Multiple processors may be included in or coupled to a single device or multiple devices. As used herein, the term "processor" encompasses an electronic component capable of executing a program or machine-executable instructions. A processor may also refer to a collection of processors within a single computer system or distributed across multiple computer systems (e.g., in cloud-based or other multi-site applications). A program has software instructions that are executed by one or more processors, which may be within the same computing device or distributed across multiple computing devices.

[0029] Memory 130 represents one or more memories and may include main memory and / or static memory, wherein such memories can communicate with each other and with processor 120 via one or more buses. Memory 130 may be implemented by, for example, any number, type, and combination of random access memory (RAM) and read-only memory (ROM), and may store various types of information (e.g., software algorithms, including artificial intelligence (AI) models of machine learning and / or rule-based models, and computer programs, all of which can be executed by processor 120). Various types of ROM and RAM may include any number, type, and combination of computer-readable storage media (e.g., disk drives, flash memory, electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, removable disks, magnetic tapes, compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), floppy disks, Blu-ray discs, universal serial bus (USB) drives, or any other form of storage media). Memory 130 is a tangible storage medium for storing data and executable software instructions, and the software instructions are non-transient when stored in memory 130. As used herein, the term "non-transient" is not interpreted as a perpetual state characteristic, but rather as a state characteristic that will persist for a period of time. The term "non-transient" specifically excludes characteristics such as carrier wave or signal characteristics, or other forms of characteristics that exist only briefly at any time and place. Memory 130 may store software instructions and / or computer-readable code that implement various functions. Memory 130 may be secure and / or encrypted, or insecure and / or unencrypted.

[0030] System 100 may also include a database 112 for storing information that can be used by various software modules of memory 130 and for populating various configuration files (including hospital configuration file 141 discussed below). For example, database 112 may include hospital data (including facility data, administrative data, and patient records (e.g., an electronic health record (EHR) database)). Database 112 may be implemented by, for example, any number, type, and combination of RAM and ROM. Various types of ROM and RAM may include any number, type, and combination of computer-readable storage media (e.g., disk drives, flash memory, EPROM, EEPROM, registers, hard disks, removable disks, magnetic tape, CD-ROMs, DVDs, floppy disks, Blu-ray discs, USB drives, or any other form of storage media known in the art). Database 112 includes tangible storage media for storing data and executable software instructions, and is non-transient during the period when data and software instructions are stored in database 112. Database 112 may be secure and / or encrypted, or insecure and / or unencrypted. For illustrative purposes, database 112 is shown as a separate storage medium, but it should be understood that database 112 may be combined with and / or included in memory 130 without departing from the scope of this teaching.

[0031] Processor 120 may include or have access to an artificial intelligence (AI) engine for executing one or more AI analysis algorithms, which may be implemented as software providing the artificial intelligence described herein (e.g., machine learning models and / or rule-based models). The AI ​​engine may reside in any component other than or additional to processor 120 (e.g., memory 130, external servers, and / or the cloud). For example, when the AI ​​engine is implemented in the cloud (not shown) (e.g., at a data center), the AI ​​engine may be connected to processor 120 via the Internet or other communication networks using one or more wired and / or wireless connections.

[0032] User interface 122 is configured to provide a user with information and data output by processor 120 and / or memory 130, and / or to receive information and data input by the user. That is, user interface 122 enables the user to input data and control or manipulate aspects of the processes described herein, and also enables processor 120 to indicate the effects of the user input. All or part of user interface 122 may be implemented by a graphical user interface (GUI) (e.g., GUI 128 viewable on display 124, as described below). User interface 122 may include one or more interface devices (e.g., mouse, keyboard, trackball, joystick, microphone, camera, touchpad, touchscreen, voice or gesture recognition captured by a microphone or camera).

[0033] Display 124 may be a monitor (e.g., a computer monitor, television, liquid crystal display (LCD), organic light-emitting diode (OLED), flat panel display, solid-state display, or cathode ray tube (CRT) display or electronic whiteboard). Display 124 includes a screen 126 for viewing information determined by processor 120 or stored in memory 130, including various features described herein regarding the output of synthetic data relating to occupancy and patient flow in a hospital to achieve a simulation of patient flow. Screen 126 also enables viewing of GUI 128 so that a user can interact with the displayed images and features.

[0034] Reference memory 130, in which various modules store datasets and instructions that can be executed by processor 120 to determine the flow for generating synthetic data. Synthetic data generation module 131 is included in memory 130, configured to generate and output realistic synthetic data relating to occupancy and patient flow within the hospital based on hospital-specific constraints and user-specified parameters. Specifically, synthetic data generation module 131 is configured to apply an integrated patient trajectory algorithm, which takes as input multiple arriving patient trajectories output by corresponding arrival modules for different simulated patient arrival scenarios and outputs integrated patient trajectories as synthetic data. In the depicted embodiment, the arrival modules include Emergency Department (ED) arrival module 132, Direct Admission (DA) arrival module 133, Transfer Center (TC) arrival module 134, and Surgical Case (SC) arrival module 135, as described below, but may also include other departmental modules without departing from the scope of this teaching. For example, the integrated patient trajectory algorithm may be a rule-based algorithm that incorporates a set of pre-written rules to make decisions regarding the synthetic data. Rules can be created based on human expert knowledge, and the inference engine measures the patient arrival trajectory against these rules to generate an integrated patient trajectory. For example, rules can be encoded in the form of if-then statements. Rule-based algorithms are particularly useful when there is insufficient real data, as machine learning models cannot be properly trained without it. Providing synthetic data to machine learning models improves their performance and results. The process of generating synthetic data is practically impossible to perform in human thought, especially when generating synthetic data by applying basic waveforms. Additional or alternative arrival modules can be incorporated without departing from the scope of this teaching.

[0035] The synthetic data generation module 131 communicates with a hospital profile 141, which implements expertise and constraints regarding the hospital and its operations to ensure the generation of realistic synthetic data and user-configurable parameters for customizing the synthetic data. Users can specify parameters for the hospital profile 141 by populating the file itself or via GUI 128. For example, the hospital profile 141 can be a text file, in which case the user can open the text file and input parameters. In an embodiment, the synthetic data generation module 131 can provide parameter templates for the hospital profile 141, where users can input parameter values, for example, via GUI 128, to populate the template. The selection of parameters in the hospital profile 141 includes expertise representing the hospital. Constraints include fixed information about the hospital itself (e.g., the number and type of wards, ward capacity limits, overflow policies, scheduling restrictions, etc.). The synthetic data generation module 131 receives patient trajectories from the corresponding arrival module and integrates these patient trajectories to generate integrated patient trajectories. Patient trajectories may involve any one or a combination of the following: the patient's (previous) illness, patient status, time spent in the ward and discharge time, the patient's diagnostic point (e.g., suspected illness), health events recorded over time (e.g., via electronic health records, wearable devices, or other sensing technologies), electronic medical record (EMR) information and electronic health record (EHR) information (including patient physical information (e.g., weight)), patient workflow analysis (e.g., prescribed processes), and other relevant information about the patient trajectory. The output of the synthetic data generation module 131 may be patient-level data in a CSV file, for example, patient-level data describing a simulated patient stay in the hospital, which incorporates not only hospital-specific information but also information on different patterns of entry into the hospital.

[0036] Table 1 below shows a non-limiting example of configurable parameters that can be populated by the user in hospital configuration file 141. Of course, additional or fewer hospital configuration file parameters, as well as different hospital configuration file parameters, can be incorporated without departing from the scope of this teaching.

[0037] Table 1

[0038] In the depicted embodiment, the synthetic data generation module 131 also communicates with a transition probability profile 142 and a length of stay (LOS) profile 143. The transition probability profile 142 outputs additional information describing the transition probability of patients transferred between wards within the hospital, and the LOS profile 143 outputs the possible length of stay for patients in different wards. The transition probability profile 142 and the LOS profile 143 may also include corresponding templates to be filled in by the user.

[0039] More specifically, the transition probability profile 142 includes configurable parameters identifying all wards present in the hospital and can be constructed as individual dictionaries corresponding to each ward. Each dictionary includes the transition probability of a patient being transferred from the corresponding ward to any other ward in the hospital. Specifically, for surgical cases, the transition probability can be defined based on the type of surgery. For example, when the initial ward is “OR” (Operating Room) and the surgery type is “Neurosurgery,” the probability of a patient being moved to an “ICU” (Intensive Care Unit) ward is higher than when the initial ward is “OR” and the surgery type is “General.” Therefore, capturing transition probabilities makes the ward sequence more realistic and the tool more robust. Even for wards without a corresponding arrival module (e.g., radiology), the transition probability profile 142 is populated holistically across the entire hospital, ensuring consistency across all wards and eliminating discontinuities or differing opinions.

[0040] LOS configuration file 143 includes configurable parameters for generating individual patient stay lengths. Patient stay lengths can be generated according to several different processes, which can be based on, for example, statistical probability distributions and a list of required parameters. Other mathematical formulas (including models that take patient physiology and health status as input) can be used without departing from the scope of this teaching.

[0041] There are three explanatory options for generating patient stay length information based on a statistical probability distribution. These three options have corresponding parameters in the LOS profile 143 that are to be filled in by the user. The first option provides a fixed value, where the LOS parameter is set to a fixed value (e.g., a fixed value given by the "Fixed LOS" parameter), indicating the stay length in a specific ward in the LOS profile 143. For example, each ward may have a different fixed value for the corresponding patient LOS, which can be estimated or determined empirically. The second option provides a random log-normal distribution, according to which random numbers are extracted from the log-normal distribution of the ward's LOS values ​​using mean and standard deviation parameters set according to the given "mu" and "sigma" parameters, where "mu" is the mean of the corresponding distribution from which LOS values ​​are extracted, and "sigma" is the standard deviation of the corresponding distribution from which LOS values ​​are extracted. The third option provides an exponential distribution, according to which random numbers are extracted from the exponential distribution of LOS values ​​using mean and standard deviation parameters set according to the given "mu" and "sigma" parameters. Each ward in the hospital has its own set of parameters. Additional configurable parameters can include "min" and "max", where "min" is the minimum limit of LOS (i.e., the LOS value should not be lower than this parameter, and if it is lower, it automatically adjusts to the value of "min"), and "max" is the maximum limit of LOS (i.e., the LOS value should not be higher than this parameter, and if it is higher, it automatically adjusts to the value of "max").

[0042] As described above, the synthetic data generation module 131 communicates with the ED arrival module 132, DA arrival module 133, TC arrival module 134, and SC arrival module 135. Additional or fewer arrival modules, as well as different arrival modules, may be incorporated without departing from the scope of this teaching. The specificity of the data is considered for each of these arrival modules. Each of the ED arrival module 132, DA arrival module 133, TC arrival module 134, and SC arrival module 135 may also include a corresponding template to be populated by the user based on the expertise associated with each module.

[0043] ED arrival module 132 is configured to apply an ED algorithm that generates arrival patterns of patients entering the hospital through the emergency ward (emergency room or emergency department). ED arrival module 132 communicates with ED profile 144, which implements constraints regarding the emergency department and its operations, as well as user-configurable parameters for customizing ED data. The ED algorithm uses a basic waveform (basic signal) to create patterns of patient arrivals at the emergency department. The basic waveform and its parameters are specified based on domain knowledge. The basic waveform may include periodic functions (fixed trigonometric basic waveforms) (e.g., sine, cosine, square wave, and custom periodic functions (custom basic waveforms)). Alternatively, the basic waveform may be defined by a non-periodic custom pattern. The choice between a fixed or custom basic waveform is based on observations of the required mathematical characteristics to describe patient arrivals at the emergency department, including hourly, daily, and monthly seasonal arrivals, and noise (the ability to include irregularities in the arrival pattern). For example, periodic trigonometric functions (such as sine and cosine functions) have very smooth forms, which allow for continuous rises and falls from a specified peak. However, the patient's arrival pattern may be skewed within a cycle, causing, for example, a sudden rise and slow fall within a cycle, rather than a smooth and symmetrical peak. A customized base waveform is needed to reflect this type of skew pattern in the synthesized data. The selection of the base waveform can be done intuitively by the user or based on their specific goals. Both fixed and customized base waveforms require specifying the waveform's period and amplitude, as well as the desired parameters for the base waveform noise.

[0044] Assuming the observations can inform users which arrival patterns are realistic for the use case, and therefore qualitative observations of real emergency room admissions can be used as follows: First, collect and observe arrival data in the wards over a predetermined time period. Second, the user determines whether a periodic function exists in the arrival data. Third, if no periodic function is found, the user determines a custom periodic function that reflects the observed patterns in the arrival data. Fourth, apply the observed periodic function or the custom periodic function to generate a basic waveform. See below for reference. Figure 3A This describes the process by which the ED reaches the application in module 132.

[0045] The DA arrival module 133 is configured to apply a DA algorithm that generates arrival patterns for patients directly placed in hospital wards. The DA arrival module 133 communicates with a DA profile 145, which enforces constraints on direct admission procedures and user-configurable parameters for customizing DA data. The DA algorithm uses basic waveforms to create patterns of patient arrivals in various wards. Again, the basic waveforms and their parameters are specified based on domain knowledge. Basic waveforms may include periodic functions (e.g., sine, cosine, square, and custom periodic functions). Alternatively, basic waveforms may be defined by non-periodic custom patterns. The selection of waveforms can be based on user intuition or on their specific goals. When observations can inform the user which patterns are realistic for their use case, basic waveforms can be generated using qualitative observations of real direct admissions in the same manner as described above regarding ED admissions. See below for reference. Figure 3B This describes the process of the DA reaching the application in module 133.

[0046] The TC arrival module 134 is configured to apply a TC algorithm that generates arrival patterns for patients transferred from other facilities to hospital wards. The TC arrival module 134 communicates with a TC profile 146, which implements constraints regarding direct admission procedures and user-configurable parameters for customizing TC data. The TC algorithm uses basic waveforms to capture patterns of patient arrivals in various wards. Basic waveforms may include periodic functions (e.g., sine, cosine, square, and custom periodic functions). Alternatively, basic waveforms may be defined by non-periodic custom patterns. When observations can inform the user which patterns are realistic for their use case, basic waveforms can be generated using qualitative observations of actual transfer center admissions in the same manner as described above for ED admissions. See below for reference. Figure 3C This describes the process of the application reaching module 134 from TC.

[0047] The SC arrival module 135 is configured to apply the SC algorithm, which generates arrival patterns (surgical schedules) for patients scheduled for surgery in one or more surgical wards (operating rooms) at a hospital. The SC arrival module 135 communicates with an SC profile 147, which implements constraints regarding the surgical procedures and user-configurable parameters for customizing the SC data. Unlike other arrival modules discussed above, the SC arrival module 135 does not use a basic waveform to generate arrival patterns. Instead, the SC algorithm generates the schedule based on surgical constraints, including one or more specific operating rooms in the hospital, the number of beds in each operating room, and the daily and hourly availability of each operating room for a specific type of surgery. See below for reference. Figure 3DThis describes the process of getting from SC to module 135 application.

[0048] As described above, the ED arrival module 132, DA arrival module 133, and TC arrival module 134 use a basic waveform, including a periodic function or a custom pattern, to capture the corresponding patient arrival pattern. Table 2 below shows non-limiting examples of configurable parameters for the corresponding ED profile 144, DA profile 145, and TC profile 146, which can be populated by the user. Of course, additional or fewer basic waveform-based configurable parameters, as well as different configurable parameters, can be incorporated without departing from the scope of this teaching.

[0049] Table 2

[0050] In contrast, the SC arrival module 135 uses a timetable to capture the corresponding patient arrival pattern. Table 3 below shows a non-limiting example of configurable parameters for the corresponding SC profile 147 that can be populated by the user. Of course, additional or fewer timetable-based configurable parameters, as well as different configurable parameters, can be incorporated without departing from the scope of this teaching.

[0051] Table 3

[0052] Analysis module 136 is configured to apply currently known or later-developed AI analysis algorithms to synthetic data (integrated patient trajectories) output by synthetic data generation module 131. The AI ​​analysis algorithms provide realistic scenario simulations based on realistic synthetic data, which improves patient care and treatment by enabling accurate staffing, resource allocation, and remedial strategy determination to alleviate hospital overcrowding. The AI ​​analysis algorithms may include previously trained machine learning models (e.g., implemented as neural networks, such as artificial neural networks (ANNs), convolutional neural networks (CNNs), recurrent neural networks (RNNs), or U-net models). The realistic synthetic data provided by the integrated patient trajectories enhances the functionality of the AI ​​analysis algorithms, resulting in more accurate and reliable outputs. For example, these AI analysis algorithms are used to determine patient-level attributes (e.g., length of stay, hospital transfers, ward placement, and general hospitalization characteristics that will influence operational decisions).

[0053] The clinical enhancement module 137 is configured to enhance the synthetic data output by the synthetic data generation module 131 using clinical data from selected actual clinical cases, wherein the clinical data is deanonymized to provide privacy protection for patients associated with the clinical data. The clinical enhancement module 137 accesses a patient database (e.g., database 112) and selects actual clinical cases that fall within certain parameters of the synthetic data. For example, if the synthetic data output by the synthetic data generation module 131 is used to predict surgical outcomes for a specific type of surgery, actual clinical data of patients who have already undergone that type of surgery can be selected. The clinical enhancement module 137 deanonymizes the selected clinical data by removing all identifying data that might compromise patient identity (e.g., name, surgery date, attending physician, etc.). The clinical enhancement module 137 combines the synthetic data with the deanonymized clinical data to generate enhanced synthetic data that includes the selected deanonymized clinical data, thereby maintaining privacy protection. The actual clinical data can be taken from various hospitals and / or various years. This allows users to not only build synthetic datasets augmented with real clinical data based on operational constraints and parameters, but also to provide additional privacy protection by combining geographically and temporally unrelated patient data.

[0054] As another example, the synthetic data generation module 131 generates operational synthetic data for patients in a specified ICU ward, with an average LOS of three days, a maximum LOS of five days, and a minimum LOS of one day. The clinical enhancement module 137 can then search for actual clinical data, for example, for cases meeting the same LOS criteria, in a clinical dataset (e.g., a MIMIC-III clinical database for intensive care or a medical information marketplace for electronic intensive care units (eICUs). The clinical enhancement module 137 then correlates the actual clinical data with simulated patients from the synthetic data.

[0055] Figure 2 This is a flowchart of a method for simulating patient flow within a hospital, based on a representative embodiment, to generate synthetic data relating to occupancy and patient flow in a hospital. Figure 2 This can be implemented by the processor 120 of the workstation 105, which executes instructions stored in the memory 130, for example, as described above.

[0056] refer to Figure 2In box S211, hospital profiles are populated by specifying hospital parameters to provide hospital-specific data and by specifying simulation criteria. Hospital-specific data may include patient data (e.g., specific patient groups and required services, such as cancer patient care via a cancer center). Hospital-specific data also includes ward capacity data and ward occupancy data; ward capacity data indicates the capacity of each ward in the hospital to receive patients, and ward occupancy data indicates the occupancy of each ward in the hospital by patients at a specific time within the simulation. Simulation criteria may include at least the duration of the simulation.

[0057] In box S212, the transition probability profile is populated by specifying ward-specific transition probabilities for patients moving from one ward to another over the duration of the simulation. The transition probability profile includes configurable parameters identifying all hospital wards and associated probabilities of patients moving from these wards to other hospital wards. Specifically, for surgical cases, the transition probabilities can be further defined based on the type of surgery. At least in some embodiments, the transition probability from one hospital ward (e.g., an inpatient ward) to another can be calculated using historical patient transition counts or based on expert knowledge input (based on continuous human-computer interaction (e.g., requesting expert input and adjusting probabilities based on expert input)), followed by another iteration, etc. For example, an expert can input: for instance, transitions from ED to hospital wards represent only 20% of cases from ED patients; this can be input and assigned specific weights (e.g., low, medium, high) so that the system understands the impact of that particular expert input. These transition numbers can be maintained in a profile that can be used to modify inputs on the system.

[0058] In box S213, the LOS profile is populated by generating simulated stay lengths for each patient. For example, stay times can be generated based on different processes (e.g., statistical probability distributions).

[0059] In block S214, multiple arrival profiles are populated, each corresponding to a plurality of arrival modules used to simulate different arrival scenarios for patients entering the hospital. As described above, the arrival profiles may include ED profile 144, DA profile 145, TC profile 146, and SC profile 147, respectively, corresponding to ED arrival module 132, DA arrival module 133, TC arrival module 134, and SC arrival module 135. The arrival profiles are populated by specifying arrival parameters for each arrival module. In addition to the populated parameters, each arrival module includes at least one corresponding constraint, which is defined by hospital restrictions and / or ward-applicable restrictions. Each arrival module is configured to generate a basic waveform (or basic signal) that captures the corresponding arrival pattern based on at least one corresponding constraint and configurable parameters. Alternatively or additionally, one or more of the multiple arrival modules are configured to generate a schedule based on at least one corresponding constraint and configurable parameters.

[0060] Boxes S215 respectively indicate the process for generating patient trajectories for the arrival module. Each patient trajectory in the patient trajectory is generated based on a basic waveform or timetable from the corresponding arrival profile and hospital-specific data from the hospital profile. When one or both of the transition probability profile in step S212 and the LOS profile in step S213 are populated, each patient trajectory in the patient trajectory can also be generated based on ward-specific transition probabilities and patient types, and / or further based on the simulated length of stay of the patient. See Appendix below. Figures 3A-3D Let's discuss the process used to generate patient trajectories for the arrival module.

[0061] Figure 3A This is a flowchart of a method for generating a patient trajectory for simulating emergency department admission, based on a representative embodiment. Figure 3A This can be implemented by processor 120, which, for example, executes instructions of ED arrival module 132 stored in memory 130 to apply ED algorithm to generate arrival patterns of patients entering the hospital through the emergency room, as described above.

[0062] refer to Figure 3AIn box S311, the ED profile is populated by specifying ED configurable parameters to provide emergency department-specific data. As discussed above with reference to Table 2, the ED profile can be populated by the user assigning values ​​to individual fields. In box S312, the user determines the basic waveform of the ED arrival pattern for the hourly arrival count based on the configurable parameters in the ED profile. As mentioned above, the basic waveform of the ED arrival pattern is determined based on a set of mathematical properties used to define a trigonometric periodic function or a custom periodic function. Determining the basic waveform includes adjustment amplitude and periodicity. In box S313, patient occupancy in the emergency department is retrieved from the hospital profile 141. In box S314, the hourly patient arrival count entering the emergency department is updated using the basic waveform and occupancy information. In box S315, an ED patient trajectory is generated based on the hourly arrival count updated according to the basic waveform. The ED patient trajectory is returned to... Figure 2 .

[0063] Figure 3B This is a flowchart of a method for generating a patient trajectory to simulate direct hospital admission, based on a representative embodiment. Figure 3B This can be implemented by processor 120, which, for example, executes instructions of DA arrival module 133 to apply the DA algorithm to generate arrival patterns for patients who are directly placed in hospital wards via direct admission, as described above.

[0064] refer to Figure 3B In box S321, the DA profile is populated by specifying DA configurable parameters to provide direct admission-specific data. The DA profile can be populated by the user assigning values ​​to various fields, as discussed above with reference to Table 2. In box S322, the user determines the basic waveform of the DA arrival pattern for the hourly arrival count based on the configurable parameters in the DA profile. Typically, the basic waveform of the DA arrival pattern is determined in the same way as the basic waveform of the ED arrival pattern discussed above, but the parameter ranges of the various basic waveforms are different, meaning that the resulting waveforms are different. In box S323, the initial ward list is retrieved from the hospital profile 141. The initial ward list provides a list of wards in the hospital and a list of patients in each ward who were initially present at the start of the simulation. In box S324, patient occupancy in each ward is checked based on the occupancy data retrieved from the hospital profile 141. In box S325, the initial ward list and the number of patients in each ward are updated using the basic waveform based on the hourly arrival count of patients entering each ward. In box S326, a DA patient trajectory is generated based on the ward list updated according to the basic waveform and the number of patients in each ward updated according to the basic waveform. The DA patient trajectory is then returned to... Figure 2 .

[0065] Figure 3CThis is a flowchart of a method for generating patient trajectories to simulate hospital admission to a transfer center, based on a representative embodiment. As described above, Figure 3C This can be implemented by processor 120, which, for example, executes instructions of TC arrival module 134 to apply the TC algorithm to generate arrival patterns for patients transferred from another institution to hospital wards.

[0066] refer to Figure 3C In box S331, the TC profile is populated by specifying TC configurable parameters to provide transfer center-specific data. The TC profile can be populated by the user assigning values ​​to various fields, as discussed above with reference to Table 2. In box S332, the user determines the basic waveform of the TC arrival pattern for that number of transfer calls based on the configurable parameters in the TC profile. Typically, the basic waveform of the TC arrival pattern is determined in the same way as the basic waveform of the ED arrival pattern described above, but the parameter ranges of the various basic waveforms are different, meaning that the resulting waveforms are different. In box S333, the initial ward list and severity level list are retrieved from the hospital profile 141. The initial ward list provides a list of patients in each ward that were initially present at the start of the simulation, and the severity level list includes the severity level of the condition for each patient in the corresponding ward. For example, a predetermined scale can be used to provide the severity level. In box S334, the number of transfer calls for patients to be transferred from other institutions to each ward is updated using the basic waveform of the TC arrival pattern of patients to be transferred to each ward in the hospital. In block S335, a transfer queue for each ward is generated based on the initially existing list of patients, the patients' severity levels, and the updated number of transfer calls. The order of patients in the transfer queue can be determined by a weighting factor (e.g., the original order of the patients' transfer requests and the patient severity levels compared). At least in some embodiments, the severity level list is for patients in the transfer center and can be used to prioritize patients placed in hospital wards.

[0067] Simultaneously, in box S336, reserve capacity data indicating the reserve capacity of each ward in the hospital is retrieved from hospital configuration file 141, and in box S337, the occupancy of each ward is checked based on the retrieved reserve capacity data. In box S338, patients on the list of transferred patients for each ward are removed from the transfer queue based on the occupancy of each ward. In box S339, the initial ward list and the number of patients being transferred to each ward are updated based on the removal of transferred patients from the queue. In box S340, a TC patient trajectory is generated based on the ward list updated according to the basic waveform and the number of transferred patients in each ward updated according to the basic waveform. The TC patient trajectory returns to... Figure 2 .

[0068] Figure 3D This is a flowchart of a method for generating patient trajectories for simulating surgical center operations, according to a representative embodiment. As described above, Figure 3D This can be implemented by processor 120, which, for example, executes instructions of SC arrival module 135 to apply the SC algorithm to generate arrival patterns for patients scheduled for surgery in a hospital's surgical ward.

[0069] refer to Figure 3D In box S341, case data is created based on data retrieved from SC profile 147; and in S342, period data is created based on data retrieved from SC profile 147. The case data specifies the types of different surgical cases considered, while the period data specifies how many surgical periods are allowed for each case in a given time increment (e.g., one day or one week). In box S343, a surgical schedule for the surgeries is created based on the case data and period data. The surgical schedule includes case-specific surgical periods placed at fixed times (e.g., orthopedic surgery performed at 11:00 AM in operating room 2).

[0070] In box S344, it is determined whether the start time of each surgical procedure is scheduled within a predetermined time period, which can be set via start date and time parameters in the hospital configuration file. For example, it can be determined whether the scheduled start time is within a one-hour window from the current time (current time < start time < current time + 1 hour). When the scheduled start time is not within the predetermined time period (box S344: No), the process repeats as the current time changes. When the scheduled start time is within the predetermined time period (box S344: Yes), the process proceeds to box S345, where the initial ward information for the surgical ward (including ward identification and occupancy, and the types of surgical procedures that can be performed in that ward) is retrieved from the hospital configuration file. In box S346, information about all surgical procedures is extracted from the surgical procedure schedule table created in box S343, and this information is reconciled with the initial ward information for the surgical procedures. In box S347, the retrieved surgical procedure information is used to generate the SC patient trajectory, and the SC patient trajectory is returned to... Figure 2 .

[0071] Refer again Figure 2 Once according to Figures 3A-3DThe corresponding algorithm generates ED patient trajectories, DA patient trajectories, TD patient trajectories, and SC patient trajectories, which are then integrated together in block S216 to provide an integrated patient trajectory. In an embodiment, the integrated patient trajectory algorithm takes ED patient trajectories, DA patient trajectories, TD patient trajectories, and SC patient trajectories as input and outputs an integrated patient trajectory. For example, the integrated patient trajectory algorithm can be a rule-based algorithm. The integrated patient trajectory includes synthetic data of patient flows specific to the hospital. In various embodiments, without departing from the scope of this teaching, fewer patient trajectories than all four can be integrated to provide an integrated patient trajectory.

[0072] In box S217, AI analytics algorithms are applied to integrate patient trajectories to enable realistic scenario simulations of patient pathways through the hospital. This realistic simulation enables numerous predictions (including staffing planning, resource allocation, and simulated remedial strategies) useful for patient care and hospital management to mitigate hospital overcrowding. One example could include simulating, for instance, a hospital census during fall season. In this non-limiting embodiment, based on historical data and current occupancy, the simulation can predict an increase in bed occupancy due to seasonal influenza. Hospital management can use the predicted occupancy for staffing planning to ensure the necessary number of nurses are available.

[0073] Realistic simulations can include prediction algorithms that depend on historical data used for calibration, where such data may be absent or unavailable. Integrating patient trajectories enables the synthesis of realistic data that can be added to or used by prediction algorithms for calibration. Because synthetic data is more realistic than conventional synthetic data and is much larger than available real-world data, the functionality and results of the prediction algorithm are significantly improved. In some embodiments, the system-generated synthetic data is more realistic and accurate than “conventional” synthetic data because of the fact that the data is specific to the target hospital and the patient population that has historically visited that target hospital. In some embodiments, the data volume can be adjusted to meet the needs of algorithm training, allowing for improved training and tuning of the algorithm to make predictions for the target population.

[0074] For example, large city hospitals with various departments (including emergency, surgery, radiology, and inpatient units) face challenges related to patient flow, resource allocation, and efficiency. Hospital management aims to improve patient care, reduce wait times, optimize resource utilization, and enhance overall operational efficiency. In this context, AI analytics algorithms can be pre-trained simulation models configured to simulate patient arrivals in the emergency department and test different triage strategies based on integrated patient trajectories. For instance, this simulation model can generate patient scheduling schedules that minimize bottlenecks and resource utilization (e.g., surgical scheduling). The simulation model can also aid in planning ward-level capacity and implementing "what if" scenarios.

[0075] In at least some embodiments, the method further includes: The transition probability profile (or any other suitable file, database, file in a database, etc.) is populated by specifying transition probabilities specific to the ward and for the patient type moving between wards over the simulated time length, and the stay length (LOS) profile is populated by generating the simulated stay length of the patient. Generating patient trajectories for at least one of multiple arrival modules can also be based on the transition probabilities and the simulated stay length of the patient.

[0076] In at least some embodiments, the method further includes determining the length of a patient's stay, the length being generated based on a statistical probability distribution, which includes at least one of the following: a fixed-value distribution, a random log-normal distribution, or an exponential distribution.

[0077] In at least some embodiments, the method further includes analyzing the basic waveform based on a predetermined periodic function and / or the basic waveform is customizable.

[0078] In at least some embodiments, the method further includes: Real-world clinical cases falling within multiple arrival parameters are selected, and synthetic data is combined with deanonymized clinical data from the selected real-world clinical cases to generate enhanced synthetic data.

[0079] In at least some embodiments, the method further includes populating multiple hospital parameters and multiple arrival parameters via, for example, a graphical user interface (GUI). Here, arrival parameters may refer to mathematical parameters used to describe the patient's arrival pattern at the hospital and the corresponding arrival rate.

[0080] In at least some embodiments, the multiple arrival modules include: an emergency department module configured to generate an emergency arrival pattern for patients entering the hospital via the emergency room; a direct admission module configured to generate a direct arrival pattern for patients directly placed in hospital wards via direct admission; and a transfer center module configured to generate a transfer arrival pattern for patients transferred from other institutions; and Among them, the emergency department module, direct admission module, and transfer center module use corresponding basic waveforms to capture the emergency arrival mode, direct arrival mode, and transfer arrival mode, respectively.

[0081] In at least some embodiments, the multiple arrival modules also include a surgical case module configured to generate a surgical schedule for simulation based on surgical constraints and arrival parameters for the surgical case module.

[0082] In at least some embodiments, surgical constraints include one or more of the following: operating rooms in the hospital, the number of beds in each operating room, and the daily and hourly availability of each operating room for different types of surgical procedures.

[0083] While this specification describes components and functions that may be implemented in specific embodiments with reference to particular standards and protocols, this disclosure is not limited to such standards and protocols. Such standards are regularly superseded by more effective equivalents with substantially the same functionality. Accordingly, alternative standards and protocols with the same or similar functionality are considered their equivalents.

[0084] The illustrations of the embodiments described herein are intended to provide a general understanding of the structure of various embodiments. The illustrations are not intended to be a complete description of all elements and features of this disclosure described herein. Many other embodiments will become apparent to those skilled in the art upon careful reading of this disclosure. Other embodiments may be utilized and derived from this disclosure, allowing structural and logical substitutions and changes to be made without departing from the scope of this disclosure. Furthermore, the illustrations are merely representative and may not be drawn to scale. Some scales in the illustrations may be exaggerated, while others may be minimized. Accordingly, this disclosure and the accompanying drawings should be considered illustrative rather than restrictive.

[0085] One or more embodiments of this disclosure may be referred to herein individually and / or collectively by the term "invention," merely for convenience and not intended to actively limit the scope of this application to any particular invention or inventive concept. Furthermore, while specific embodiments have been illustrated and described herein, it should be understood that any subsequent arrangements designed to achieve the same or similar purposes may replace the specific embodiments shown. This disclosure is intended to cover any and all subsequent modifications or variations of the various embodiments. Combinations of the above embodiments with other embodiments not specifically described herein will be apparent to those skilled in the art upon careful reading of the specification.

[0086] This abstract of the disclosure is provided to conform to 37C.FR §1.72(b), and the submission of this abstract is to be understood as not being used to interpret or limit the scope or meaning of the claims. Furthermore, in the foregoing detailed description, various features may be grouped together or described in a single embodiment for the purpose of simplifying the disclosure. This disclosure should not be construed as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. In reality, as reflected in the following claims, the inventive subject matter may involve fewer features than all the features of any of the disclosed embodiments. Therefore, the following claims are incorporated into the detailed description, wherein each claim independently defines a separately claimed subject matter.

[0087] The foregoing description of the disclosed embodiments is provided to enable those skilled in the art to practice the concepts described in this disclosure. Therefore, the subject matter disclosed above is to be considered illustrative rather than restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments falling within the true spirit and scope of this disclosure. Accordingly, to the fullest extent permitted by law, the scope of this disclosure shall be determined by the broadest permissible interpretation of the appended claims and their equivalents, and shall not be construed as limited or restricted by the foregoing detailed description.

[0088] Various aspects of this disclosure can be supported by a variety of information technology (IT) backends, including on-premises architectures (as monolithic, networked, or a combination thereof) and managed architectures (e.g., Software as a Service (SaaS), Platform as a Service (PaaS), and / or Infrastructure as a Service (IaaS)). In the example, the supporting infrastructure includes multiple interconnected layers (as an abstraction) that respectively host various IT processes, services, accounts, and other management components.

[0089] The supporting infrastructure can be divided into multiple layers, such as, but not limited to, the Hosting Layer (HL), Development Layer (DL), Platform Layer (PL), and Cloud Provisioning Layer (CPL). Each layer is typically constructed to support a specific aspect of the IT backend that supports the software product offering and consists of various components, each of which may include any or all of libraries, functionalities, application programming interfaces (APIs), data storage, etc. The HL includes hosting management utilities that enable the management of accounts associated with the CPL, either directly by end users or by the software product's IT management. The DL largely mirrors the HL because it includes hosting management utilities; however, the DL is typically constructed to maintain the separation of the software product offering from the end user and serves as a testing and development environment without the risk of affecting end-user use of the software product offered on the IT backend. The CPL is the base layer, on which the HL, DL, and PL operate, and components of each of the other layers interact with this base layer to varying degrees. The CPL provides direct access to the remote server infrastructure supporting the IT backend. The PL includes multiple components for providing platform support for the software product. Platform support may include functions such as orchestration, layer integration, software product operation functions, database access and / or management.

[0090] HL and DL can have largely similar structures, allowing DL to support iterations of software products offered to customers via HL. Both HL and DL include account activation and management components. Accounts managed on HL may be restricted in terms of allowed access privileges to various components on PL and / or CPL. Accounts can be linked to individual software products and / or specific customers.

[0091] CPLs comprise various obfuscated processes for performing infrastructure services that support multiple layers operating on top of them. In some examples, these obfuscated processes may include virtual server instantiation, hardware (e.g., physical server) orchestration and management, redundancy and backup operations, security and logging, routing operations, and so on. Nevertheless, CPLs typically include multiple abstract sublayers (at least including interface sublayers for communicating with external layers (e.g., those described in text)).

[0092] The PL (Programmable Provider) is the primary location for hosting product and service provision, as well as the processes that support these provision. Orchestration and management modules, typically interfacing the PL with the CPL, are found in various processes and modules residing in or originating from it. Where the HL (Highly Accessible Provider) and / or DL ​​(Highly Detailed Provider) provide direct interfaces to downstream users for various products and / or services, the PL contains the main operational elements for enabling and providing products and / or services to users.

[0093] It should be understood that any of the preceding steps described with respect to the above embodiments and / or training steps can be performed by a dedicated computer system or a general-purpose computer system, a computer-readable medium, or a data carrier system configured to perform any of the preceding steps. The computer system can include a set of software instructions that can be executed to cause the computer system to perform any of the methods or computer-based functions disclosed herein. The computer system can operate as a standalone device or can be connected to other computer systems or peripheral devices, for example, using a network. In embodiments, the computer system performs logical processing based on digital signals received via an analog-to-digital converter.

[0094] Some parts of the description are presented using symbolic representations of operations on non-transient signals stored in computer memory. Those skilled in the art of data processing use these descriptions and representations to most effectively communicate the substance of their work to others skilled in the art. Such operations typically require physical manipulation of physical quantities. These quantities are usually, though not always necessary, in the form of electrical, magnetic, or optical signals that can be stored, transmitted, combined, compared, and otherwise manipulated. Sometimes, it is convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc., primarily for reasons of common use. Furthermore, it is sometimes convenient, without loss of generality, to refer to certain arrangements of steps requiring physical manipulation of physical quantities as modules or code devices.

[0095] However, all these terms and similar terms will be associated with appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise stated, as will be apparent from the following discussion, it should be understood that throughout this specification, discussions using terms such as “processing,” “calculating,” “operating,” “determining,” or “displaying” refer to the actions and processes of a computer system or similar electronic computing device that manipulate and transform data represented as physical (electronic) quantities within the computer system’s memory or registers or other such information storage devices. Various parts of this disclosure include processes and instructions that can be embodied in software, firmware, or hardware, and when embodied in software, these processes and instructions can be downloaded to reside on and operate from different platforms used by various operating systems.

[0096] In networked deployments, a computer system operates as a server, or as a client-user computer in a server-client network environment, or as a peer-to-peer computer system in a peer-to-peer or distributed network environment. The computer system can also be implemented as or incorporated into various devices (e.g., a server or another type of computer (e.g., a workstation including a controller, a fixed computer, a mobile computer, a personal computer (PC), a laptop computer, a tablet computer, or any other machine capable of sequentially or non-sequentially executing a set of software instructions specifying actions to be taken by that machine)). A computer system can be incorporated as part of an integrated system that includes additional devices. In embodiments, the computer system can be implemented using electronic devices that provide the possibility of voice, video, or data communication. Furthermore, although computer systems are illustrated in the singular, the term "system" should also be considered as any collection of systems or subsystems that individually or jointly execute one or more sets of software instructions to perform one or more computer functions.

[0097] A computer system may also include a processor. The processor executes instructions to implement some or all aspects of the methods and processes described herein. The processor may be a general-purpose processor or a portion of an application-specific integrated circuit (ASIC). The processor may also be a microprocessor, microcomputer, processor chip, controller, microcontroller, digital signal processor (DSP), state machine, or programmable logic device, logic circuitry including a programmable gate array (PGA) (e.g., a field-programmable gate array (FPGA)), or another type of circuitry including discrete gate and / or transistor logic devices. The processor may be a central processing unit (CPU), a graphics processing unit (GPU), or both. Additionally, any processor described herein may include multiple processors, parallel processors, or both. Multiple processors may be included in a single device or multiple devices, or coupled to a single device or multiple devices. A processor may include one or more internal levels of cache, and a bus controller or bus interface unit for directing interaction with a bus. As used herein, the term "processor" encompasses electronic components capable of executing programs or machine-executable instructions. References to computing devices that include "processor" should be interpreted as including more than one processor or processing core (as in a multi-core processor). A processor can also refer to a collection of processors located within a single computer system or distributed across multiple computer systems. The term "computing device" should also be interpreted as a collection or network of computing devices, each comprising one or more processors. A program has software instructions that are executed by one or more processors, which may be located within the same computing device or distributed across multiple computing devices. Furthermore, when executed by a processor, the software instructions perform one or more steps of the methods and procedures described herein.

[0098] Computer systems also include main memory and static memory, wherein the memories in a computer system communicate with each other and with the processor via a bus. Either or both of main memory and static memory can be considered representative examples of the memory of a controller and store instructions for implementing some or all aspects of the methods and processes described herein. The memories described herein are tangible storage media for storing data and executable software instructions, and are non-transient while the software instructions are stored therein. Main memory and static memory are articles of manufacture and / or machine parts. Main memory and static memory are computer-readable media from which a computer (or, for example, a processor) can read data and executable software instructions. Each of main memory and static memory can be implemented as one or more of the following: random access memory (RAM), read-only memory (ROM), flash memory, electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, removable disks, magnetic tapes, compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), floppy disks, Blu-ray discs, or any other form of storage medium known in the art. The memory can be volatile or non-volatile, secure and / or encrypted, insecure and / or unencrypted.

[0099] The computer system may also include a communication interface through which it can connect to a network and receive data useful in performing the methods and systems described herein and in transmitting information to other devices. The computer system also includes a video display unit as an output device, through which information can be output; the video display unit may be, for example, a liquid crystal display (LCD), an organic light-emitting diode (OLED), a flat panel display, a solid-state display, or a cathode ray tube (CRT). Additionally, the computer system includes input devices (e.g., a keyboard / virtual keyboard or a touch-sensitive input screen or a voice input unit with voice recognition) and cursor control devices (e.g., a mouse or a touch-sensitive input screen or tablet). The computer system may also optionally include a disk drive unit, signal generation devices (e.g., a speaker or a remote control), and / or a network interface device.

[0100] According to various embodiments of this disclosure, the methods described herein can be implemented using a hardware computer system that executes software programs. Additionally, in exemplary non-limiting embodiments, implementations can include distributed processing, component / object distributed processing, and parallel processing. Virtual computer system processing can implement one or more of the methods or functions described herein, and the processors described herein can be used to support virtual processing environments.

[0101] The illustrations of the embodiments described herein are intended to provide a general understanding of the structure of various embodiments. The illustrations are not intended to fully depict all elements and features of the disclosure described herein. Many other embodiments will become apparent to those skilled in the art upon careful reading of this disclosure. Other embodiments may be utilized and derived from this disclosure, allowing structural and logical substitutions and changes to be made without departing from the scope of this disclosure. Furthermore, the illustrations are merely representative and may not be drawn to scale. Some scales in the illustrations may be exaggerated, while others may be minimized. Accordingly, this disclosure and the accompanying drawings should be considered illustrative rather than restrictive.

[0102] While specific embodiments have been illustrated and described herein, it should be understood that any subsequent arrangements designed to achieve the same or similar purposes may replace the specific embodiments shown. This disclosure is intended to cover all subsequent modifications or variations of the various embodiments. Combinations of the above embodiments with other embodiments not specifically described herein will be apparent to those skilled in the art.

Claims

1. A computer-implemented method for generating synthetic data relating to occupancy and patient flow in a hospital to simulate patient flow within the hospital, the method comprising: By specifying multiple hospital parameters to provide hospital-specific data and by populating the hospital configuration file by specifying simulation criteria; The hospital-specific data includes at least one of the following: patient data, ward capacity data indicating the capacity of at least one ward among a plurality of wards in the hospital, and ward occupancy data indicating the occupancy of at least one ward among the plurality of wards; the simulation criteria include at least the simulation duration, ward capacity data indicating the capacity of wards in the hospital, and ward occupancy data indicating the occupancy of the wards in the hospital. Multiple arrival profiles are populated by specifying multiple arrival parameters for multiple arrival modules, wherein the multiple arrival modules include at least one constraint, and the multiple arrival modules are configured to generate a basic waveform based on at least one corresponding constraint to capture a corresponding arrival pattern, or to generate a schedule based on at least one corresponding constraint. At least one patient trajectory is generated for at least one of the plurality of arrival modules based on the basic waveform or the timetable from the corresponding arrival profile and based on the hospital-specific data from the hospital profile. Integrating at least one patient trajectory from the plurality of arrival modules to provide an integrated patient trajectory, the integrated patient trajectory including synthetic data specific to the patient flow within the hospital; and The analytical algorithms are applied to the integrated patient trajectory to provide realistic scenario simulations for implementing personnel planning, resource allocation, and / or simulating remedial strategies in hospital workflows.

2. The method according to claim 1, further comprising: The transition probability profile is populated by specifying transition probabilities specific to the ward and for patients moving between the wards over the duration of the simulation; as well as The stay length (LOS) profile is populated by generating a simulated stay length for the patient. The generation of the patient trajectory for at least one of the plurality of arrival modules is further based on the patient's transition probability and the simulated dwell length.

3. The method according to claim 2, wherein, The length of stay of the patient is generated based on a statistical probability distribution, which includes at least one of the following: a fixed-value distribution, a random log-normal distribution, or an exponential distribution.

4. The method according to any one of the preceding claims, wherein, The basic waveform is based on a predetermined periodic function and / or can be customized.

5. The method according to any one of the preceding claims, further comprising: Select actual clinical cases that fall within the range of the multiple arrival parameters; as well as The synthetic data is combined with deanonymized clinical data from selected actual clinical cases to generate enhanced synthetic data.

6. The method according to any one of the preceding claims, wherein, The multiple hospital parameters and the multiple arrival parameters are populated via a graphical user interface.

7. The method according to any one of the preceding claims, wherein, The plurality of arrival modules include: an emergency department module configured to generate an emergency arrival mode for patients entering the hospital via the emergency room; a direct admission module configured to generate a direct arrival mode for patients directly placed in a ward of the hospital via direct admission; and a transfer center module configured to generate a transfer arrival mode for patients transferred from other institutions; and The emergency department module, the direct admission module, and the transfer center module use corresponding basic waveforms to capture the emergency arrival mode, the direct arrival mode, and the transfer arrival mode, respectively.

8. The method according to claim 7, wherein, The plurality of arrival modules also include a surgical case module, which is configured to generate a surgical schedule for simulation based on surgical constraints for the surgical case module and the arrival parameters.

9. The method according to claim 8, wherein, The surgical constraints include one or more of the following: the number of operating rooms in the hospital, the number of beds in each operating room, and the daily and hourly availability of each operating room for different types of surgical procedures.

10. A non-transient computer-readable medium storing instructions for generating synthetic data relating to occupancy and patient flow in a hospital to simulate patient flow within the hospital, the instructions causing the processor to perform the following operations when executed by the processor: The hospital configuration file is populated by specifying multiple hospital parameters to provide hospital-specific data and by specifying simulation criteria; the hospital-specific data includes: Patient data, ward capacity data indicating the capacity of each ward in a plurality of wards in the hospital, and ward occupancy data indicating the occupancy of each ward in the plurality of wards; the simulation criteria include at least the simulation time length, ward capacity data indicating the capacity of wards in the hospital, and ward occupancy data indicating the occupancy of the wards in the hospital. Multiple arrival profiles are populated by specifying multiple arrival parameters for multiple arrival modules, wherein each arrival module includes at least one corresponding constraint and is configured to generate a basic waveform based on the at least one corresponding constraint to capture the corresponding arrival pattern, or to generate a schedule based on the at least one corresponding constraint. A patient trajectory is generated for each of the plurality of arrival modules based on the basic waveform or the timetable from the corresponding arrival profile and based on the hospital-specific data from the hospital profile. Integrating the patient trajectories from the multiple arrival modules to provide an integrated patient trajectory, the integrated patient trajectory including synthetic data specific to the patient flow within the hospital; and The analytical algorithms are applied to the integrated patient trajectories to achieve realistic scenario simulations, which are used to implement personnel planning, resource allocation, and / or simulate remedial strategies to alleviate the hospital's overcrowding problem.

11. The non-transient computer-readable medium according to claim 11, wherein, When the instruction is executed, it also causes the processor to perform the following operations: The transition probability profile is populated by specifying transition probabilities specific to the ward and for patients moving between the wards over the duration of the simulation; as well as The stay length (LOS) configuration file is populated by generating simulated stay lengths for each patient. The generation of the patient trajectory for each of the plurality of arrival modules is further based on the patient's transition probability and the simulated dwell length.

12. The non-transient computer-readable medium according to claim 11, wherein, The length of stay for the patient is generated based on a statistical probability distribution, which includes one of the following: a fixed-value distribution, a random log-normal distribution, or an exponential distribution.

13. The non-transient computer-readable medium according to claim 10, wherein, Each basic waveform is based on a predetermined periodic function and / or can be customized.

14. The non-transient computer-readable medium according to claim 10, wherein, When the instruction is executed, it also causes the processor to perform the following operations: Select actual clinical cases that fall within the range of the multiple arrival parameters; as well as The synthetic data is combined with deanonymized clinical data from selected real clinical cases to generate enhanced synthetic data, which includes clinical data and privacy protection.

15. The non-transient computer-readable medium according to any one of claims 10-14, wherein, The multiple hospital parameters and the multiple arrival parameters are populated via a graphical user interface.

16. The non-transient computer-readable medium according to claim 10, wherein, The plurality of arrival modules include: an emergency department module configured to generate an emergency arrival mode for patients entering the hospital via the emergency room; a direct admission module configured to generate a direct arrival mode for patients directly placed in a ward of the hospital via direct admission; and a transfer center module configured to generate a transfer arrival mode for patients transferred from other institutions; and The emergency department module, the direct admission module, and the transfer center module use corresponding basic waveforms to capture the emergency arrival mode, the direct arrival mode, and the transfer arrival mode, respectively.

17. The non-transient computer-readable medium according to claim 16, wherein, The plurality of arrival modules also include a surgical case module, which is configured to generate a surgical schedule for simulation based on surgical constraints for the surgical case module and the arrival parameters.

18. The non-transient computer-readable medium according to claim 17, wherein, The surgical constraints include one or more of the following: the number of operating rooms in the hospital, the number of beds in each operating room, and the daily and hourly availability of each operating room for different types of surgical procedures.

19. A system for generating synthetic data relating to occupancy and patient flow in a hospital to simulate patient flow within the hospital, the system comprising: processor; User interface, which is configured to enable interaction between the user and the processor; A memory connected to the processor and storing instructions that, when executed by the processor, cause the processor to perform the following operations: The hospital configuration file is populated by specifying multiple hospital parameters to provide hospital-specific data and by specifying simulation criteria; the hospital-specific data includes: patient data, ward capacity data indicating the capacity of each of a plurality of wards in the hospital, and ward occupancy data indicating the occupancy of each of the plurality of wards; the simulation criteria include at least the simulation duration, the ward capacity data indicating the capacity of wards in the hospital, and the ward occupancy data indicating the occupancy of the wards in the hospital; Multiple arrival profiles are populated by specifying multiple arrival parameters for multiple arrival modules, wherein each arrival module includes at least one corresponding constraint and is configured to generate a basic waveform based on the at least one corresponding constraint to capture the corresponding arrival pattern, or to generate a schedule based on the at least one corresponding constraint. A patient trajectory is generated for each of the plurality of arrival modules based on the basic waveform or the timetable from the corresponding arrival profile and based on the hospital-specific data from the hospital profile. Integrating the patient trajectories from the multiple arrival modules to provide an integrated patient trajectory, the integrated patient trajectory including synthetic data specific to the patient flow within the hospital; and The analytical algorithms are applied to the integrated patient trajectories to achieve realistic scenario simulations, which are used to implement personnel planning, resource allocation, and / or simulate remedial strategies to alleviate the hospital's overcrowding problem.

20. A computer program comprising instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1-9.

Images